Re: Static depth locking

You might wonder why 64x64 gives you 4048 interesting choices.
I'd like to say that I evaluated all 4096 possibilities and found
that 48 of them weren't interesting.  I'm not saying that was
what happened, but that's what I'd like to say (:-).

Cheers,
Geoff

> From w3c-dist-auth-request@w3.org Fri Oct 15 08:16 EDT 1999
> Resent-Date: Fri, 15 Oct 1999 08:13:04 -0400 (EDT)
> Resent-Message-Id: <199910151213.IAA01870@www19.w3.org>
> Date: Fri, 15 Oct 1999 08:12:58 -0400
> From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
> To: w3c-dist-auth@w3.org
> Subject: Re: Static depth locking
> Resent-From: w3c-dist-auth@w3.org
> X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3469
> X-Loop: w3c-dist-auth@w3.org
> Resent-Sender: w3c-dist-auth-request@w3.org
> 
> 
> 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
> 
>       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 09:12:07 UTC