Static depth locking

• From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
• Date: 1999年10月15日 07:43:44 -0400
• To: w3c-dist-auth@w3.org
• Message-Id: <9910151143.AA19732@tantalum>

Here is (what I consider) to be an extremely sensible proposal from
Alan Babich (from a few months ago). He basically says that if you
are going to do depth locking, it should be static, i.e. it should
be a lock on the current members of the collection. If you MOVE
things into and out of collections (because you have the appropriate
lock tokens for the appropriate collections), it has no effect on
the locks on those resources.
This not only has very straightforward semantics (a depth lock is just
a macro operation to produce and remove a large number of singleton locks),
but is also compatible with versioning (it is the dynamic aspect of current
depth locking that is the primary problem).
I'll include Alan's message here in case you don't have it memorized (:-).
Cheers,
Geoff
 From: "Babich, Alan" <ABabich@filenet.com>
 Date: Thu, 5 Aug 1999 15:38:42 -0700 
 Why don't we do this:
 When you lock a collection:
 depth 0: 
 shared lock placed on the collection resource: 
	 no one can add or delete members
 exclusive lock placed on the collection resource: 
	 only you can add or delete members.
 depth 1:
 shared lock on coll.: no one can add or delete members.
		 First level members that exist at that time have
		 a shared lock placed on them.
 exclusive lock on coll.: only you can add or delete members.
		 First level members that exist at that time have
		 an exclusive lock placed on them.
 depth infinity:
 shared lock on coll.: no one can add or delete members.
		 Members at any level(including subcollections)
		 that exist at that time have
		 a shared lock placed on them.
 exclusive lock on coll.: only you can add or delete members.
		 Members at any level (including subcollections)
		 that exist at that time have
		 a shared lock placed on them.
 When a resource is moved out of or into a collection, the lock(s)
 of the resource don't change (assume the move is allowed).
 No locks are ever created or deleted as a result of an ordinary
 resource or collection resource being moved (assume the move is
 allowed).
 When you unlock a collection, depth n, you do the inverse
 of the operation described above on the members that exist
 at the time the unlock of the collection is executed.
 Remember that a resource can be in multiple collections at
 the same time. In fact, in some systems, that is the normal
 case. If a resource X is in two collections C1 and C2,
 locking C1 does not prevent the resource X from being removed
 from collection C2. Nor does it prevent the resource X from
 being inserted into collection C3. There are no locks
 placed or removed as side effects of MOVE. Only LOCK,
 UNLOCK, and DELETE mess with locks.
 Alan Babich

Received on Friday, 15 October 1999 07:43:48 UTC