jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Toper" <nto...@gmail.com>
Subject Re: Google Summer of Code project for Jackrabbit
Date Wed, 24 May 2006 16:03:02 GMT
You are right: there are two different issues there so possibly two
different locking strategies: one for backup and one for restoring.

We want to cover for now only one use case: the regular backup of data. You
would call the tool through a cron everyday at midnight for instance.

There is another use case, we need to work on later (after the first project
for Google is completed): exceptional backup. For instance, before a
migration between different version. From my point of view, I would like

Are those use cases covering your needs?

Backup
We need to have a coherent image of the system. For a given workspace, is
the read access always coherent and consistant? I would prefer to avoid
locking the workspace since we are backuping a lot of data and it is going
to take some times.

A workspace lock might not even solve all issues. Have anyone of you already
solved this? If yes how?

Restore
I propose to actually lock the workspace while restoring: a restore
operation is rare and would delete the previous content. There shouldn't be
any other operations taking place.

Is this approach correct?

Nicolas


On 5/24/06, David Kennedy <davek@us.ibm.com > wrote:
>
> Is the intent to lock out the entire workspace while backup or restore is
> occurring......no writes?!  Can the transactions that occur during backup
> be recorded and played back to the backup system to avoid having to lock
> the entire workspace?
>
> Restore is a different issue though....which takes precedence: non-restore
> operations that occur during restore or the nodes from the backup?  Is it
> feasible to restore clusters (transitive closure containing references) of
>
> nodes?  Ideally we wouldn't have to lock the entire workspace.
>
> David
>
>
>
> "Nicolas Toper" < ntoper@gmail.com>
> 05/24/2006 10:12 AM
> Please respond to
> dev@jackrabbit.apache.org
>
>
> To
> dev@jackrabbit.apache.org, tobias.bocanegra@day.com
> cc
>
> Subject
> Re: Google Summer of Code project for Jackrabbit
>
>
>
>
>
>
> Hi Tobias,
>
> Thanks for your feedback.
>
> I assume I would need to lock the workspace using the getLockManager of
> WorkspaceImpl.
>
> Are those lock "time outted"? I mean for instance the backup application
> crashes, I had a lock on a Workspace, I would need to clean it as soon as
> possible. If they are not, maybe we should add it in JackRabbit through
> for
> instance a lease.
>
> What do you think?
>
> nico
> My blog! http://www.deviant-abstraction.net !!
>
>
> On 5/24/06, Tobias Bocanegra < tobias.bocanegra@day.com > wrote:
> >
> > hi nicolas,
> > sounds very promising. just one important comment so far:
> >
> > > - All updates and read are isolated through transactions. Do we need
> to
> > > define a locking strategy? If I am correct, I can read a node even
> > though it
> > > is locked and it is threadsafe. You don't commit an incoherent
> > modification.
> >
> > thats not quite true, they are only "READ COMMITTED" isolated. i.e.
> > you need to lock the entire workspace before you can perform a backup.
> >
> > regards, tobi
> > --
> > -----------------------------------------< tobias.bocanegra@day.com >---
> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> > T +41 61 226 98 98, F +41 61 226 98 97
> > -----------------------------------------------< http://www.day.com >---
> >
>
>
>


-- 
a+
nico
My blog! http://www.deviant-abstraction.net !!

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message