Vikas, Thank you very much. I'll do my best to make this project a success.
No, it wil be actually covered, this is why we don't use the JCR API only (we would have had a generic tool used for all JCR compliant repositories). This part was describing other approaches we quit exploring. nicolas On 5/24/06, Vikas Bhatia <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > 05/24/2006 10:12 AM > Please respond to > dev@jackrabbit.apache.org > > > To > dev@jackrabbit.apache.org, [EMAIL PROTECTED] > 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 < [EMAIL PROTECTED] > 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 > > -- > > -----------------------------------------< [EMAIL PROTECTED]>--- > > 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 !!
