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