Re: LOCK Scenarios

   From: ccjason@us.ibm.com

      <JC>  ...  The point is whether
      a LOCK that is rooted (singleton or not) at the destination
      URI survives. </JC>

   <gmc>
   I see at least two reasons in favor of deleting the lock:

   - A MOVE/COPY just does a regular delete (with deletion of all locks),
   rather than a "special delete" which deletes all locks except for the
   one rooted at the destination URI.

   - The MOVE/COPY protocol doesn't have to deal with the complexity of
   applying the old lock to the new resource.  I can easily imagine the
   creation of certain types of locks that only apply to certain types of
   resources.  The MOVE/COPY protocol would then have to deal with all
   the error conditions that LOCK has to deal with.
   </gmc>

   <jc> The first reason would not be significant if we added the
   optional capability into DELETE that I suggested.  I pointed out
   why it would be useful to add this capability to DELETE.

<gmc/> I agree that adding the capability to DELETE would be more
uniform than special-casing it for MOVE, but I'd prefer not having
it in either case (for simplicity).

   The second problem would also be possible if the parent of the destination
   had a depth lock that was in conflict with the new resource(s) at the
   destination. If such class of locks exist, then
   the checking needs to be there anyway.  Just one more lock to
   check.  (Similar argument to what you use below... except
   supporting the opposite position.)
   </jc>

<gmc/> I advocate removing "depth" locking from the spec
(in the "Locking: Implementation Considerations" thread)
for other reasons.

<gmc/> In general, I am against all bits of the
protocol which cause a lock to be "inherited", since this forces
all the "resource creation" methods to have to deal with all
the "LOCK" failure cases.  So I'm against:
- depth locking
- lock-null resources
- keeping the lock on the destination of a MOVE/COPY

      <JC>  ...  A scenario is...  /a/b  exists
      and is a resource... not a collection.  We want to replace it
      with a new resource that is a collection.  
      Now if one wants to accomplish this atomically (with
      LOCKS), right now one has several choices. ...

   <gmc> I think this is better handled by just saying (as suggested by
   Yaron) that a COPY/MOVE should be performed atomically, and not bother
   with trying to use locking to achieve atomicity of COPY/MOVE.  </gmc>

   <JC>
   This wouldn't be addressing the issue of atomicity of the COPY/MOVE...
   although it would achieve that.  It would be addressing the atomicity
   of the COPY/MOVE followed by something else if the client wanted it.

I don't believe that LOCK's are a good technique for achieving
atomicity of an arbitrary set of operations following the COPY/MOVE.
The main problem is that a LOCK is a very coarse form of control, i.e.
none of the properties or bodies of any of the members of a depth infinity
lock can be modified by anyone.  In a distributed authoring context,
I believe an optimistic "modify/merge" paradigm scales much better.
As long as the MOVE/COPY operations are atomic, you can perform all your
changes in a personal copy, and then MOVE/COPY the result to its final
destination.

   This capability addresses the same
   need that lock-null resources do now.  Without them, you'd have to
   create the resource and then lock them and then do whatever else
   you had in mind.  That's why I suggest that if we don't want this
   capability, we have to wonder about lock-null resources.
   </JC>

I agree, and am against lock-null resources.  I believe the
protocol could be simplified with very little loss of functionality
by just saying that if you want to achieve the effect of a lock-null
resource, you just create an empty resource (e.g. a resource with
an empty body) and then lock that real resource.

So to summarize, I'm in favor of:
- deleting lock-null resources from the spec
- deleting depth locking from the spec
- otherwise leaving alone the current wording in the spec
  of the effect of delete/move on locks

Cheers,
Geoff

Received on Thursday, 19 August 1999 10:03:41 UTC