Static depth locking

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