jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vikas Bhatia" <vik...@gmail.com>
Subject Re: Google Summer of Code project for Jackrabbit
Date Wed, 24 May 2006 15:10:29 GMT
Nicolas,

Congratulations on the project.

You mentioned
Working on the JCR API level only. The problem with this approach is that
the JCR API
does not specify any way to import or directly modify version histories or
node types.

Does this mean, importing and exporting version histories will not be
covered by your project?

Vikas.

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 >---
> >
>
>
>

Mime
View raw message