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 14:26:14 GMT
Hi Miro,

Actually, my text was unclear on this points.

 About PM
The tool will be extensible: At first, we would support one PM but it will
be easy to add new one, this way you can for instance backup to a remote DB
(useful in some cases). To be able to support this, I need to transfer a
specific workspace into the backup one (using the right PM) and save the
content of the PM (so for a file system PM, the directories, for a DB, I'd
need to call an external tool probably or launch some SQL requesrs).

Locking strategy
The transactions issue is related to the transfer from one Workspace to
another one: what if in between, someone commit a Node and make the
workspace incoherent (on an application level) and at the same time the
backup would be done.

Is this something that could happen? If yes, we need to add a lock; if not
we don't need them since if a commit occur the data will just be slightly
out of sync, but still coherent. We want to support for now regular backup
the kind you do with mysqldump.

The question behind is about performance: if we do not have to acquire lock,
it is definitely better both for the backup and for JackRabbit.

About the project idea: all the merit should go to Jukka. Jackrabbit is
still new so the support tools are only starting to appear. Besides, some
might be taken care of by the industry (Covalent for Apache for instance).


On 5/24/06, Miro Walker <miro.walker@cognifide.com> wrote:
> Another quick point on the same (similar?) issue - you have mentioned
> that you only intend to support XMLPersistenceManager or ObjectPM, in
> which case it would appear transaction-related issues are irrelevant, as
> neither of these PMs support transactions. Or have I misunderstood?
> Great idea for a project, though - jackrabbit is sorely lacking
> operational support tools in general, and backup is a great first step.
> miro
> -----Original Message-----
> From: tobias.strasser@gmail.com [mailto:tobias.strasser@gmail.com] On
> Behalf Of Tobias Bocanegra
> Sent: 24 May 2006 14:35
> To: dev@jackrabbit.apache.org
> Subject: Re: Google Summer of Code project for Jackrabbit
> 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 >---

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

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