Re: Static depth locking

Geoff,
I like this, but let's see how many cases are left even after these
simplifications. In addition, I still think we have a problem with locks moving
with a resource when the move goes across server boundries. Its the old rebind
vs. copy/delete sementics of move. We can move the lock for rebind semantics,
but can't for copy/delete. I think your suggestion was that MOVE across servers
always fails unless the collaborating servers can support distributed bind.
Client applications that want to do a MOVE across servers can hide the operation
in a COPY/DELETE. I am also assuming that locks aren't copied. Is this correct?





"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 10/15/99 08:12:58 AM

To:   w3c-dist-auth@w3.org
cc:

Subject:  Re: Static depth locking




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 12:02:36 UTC