Subject: Static depth locking

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 15 Oct 1999 07:43:44 -0400

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" <[email-masked]>
   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

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 15 Oct 1999 08:12:58 -0400

Ooops.  Forgot one comment.  I would modify Alan's proposal to say:

Only LOCK and UNLOCK can add or remove a lock to a resource.

In particular, DELETE does not add or remove locks on resources.
The reason is that a DELETE simply modifies the state of a collection
(by removing one of its bindings).  There still can be other bindings
to that resource, and the lock should continue to apply.  Only if
the last binding to a resource is deleted can the server garbage collect
that resource, which effectively deletes the lock.

I believe that the simplicity of this rule far outweighs any benefits
achieved by special casing MOVE's and DELETE's (and dynamic depth locking),
both from a clients perspective (it can predict what operation will have
what effect) and from a servers perspective (it doesn't have to worry
about how to move/delete locks based on combinations of the user request
and the state of the arguments to that request).

To give a flavor of the complexity of deciding this behavior otherwise,
consider the following variants of locking for a MOVE operation:

pick 1 from the following 4 choices:
Source is unlocked.
Source inherits depth infinity lock.
Source is locked.
Source contains member(s) with locks.

pick 1 from the following 2 choices:
Parent of Source is unlocked.
Parent of Source is depth 0 locked.

pick 1 from the following 2 choices:
Lock is a regular lock.
Lock is a null lock.

pick 1 from the following 2 choices
Lock is by requestor.
Lock is by other.

pick 1 from the following 2 choices
Lock is through this mapping.
Lock is through different mapping.

That gives us 64 interesting Source combinations.

Now do the same for the Destination.

That gives us 4048 interesting combinations of Source and Destination
locking states for a MOVE.  This situation is not conducive to enumerating
the behavior for each interesting combination.

Cheers,
Geoff

      Why don't we do this:

      Alan Babich