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