W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

Re: Static depth locking

From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
Date: Fri, 15 Oct 1999 12:32:59 -0400
Message-Id: <9910151632.AA19948@tantalum>
To: w3c-dist-auth@w3.org

   From: jamsden@us.ibm.com

   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 agree, but I'd state it a little differently:

Neither MOVE (rebind) nor COPY "moves" a lock (only an explicit UNLOCK
and LOCK can do that).  The difference between a MOVE and a
COPY/DELETE is that one adjusts bindings to an existing resource
(leaving the locks in place) while the other creates a new resource
(which will not be locked).  Neither one moves locks.

   think your suggestion was that MOVE across servers always fails unless
   the collaborating servers can support distributed bind.

Yes, but note that if there is only one binding to a resource, a cross
server MOVE presents no bindings challenges, because there will be no
cross-server bindings that result from the MOVE.  This is orthogonal
to the locking question though.

   applications that want to do a MOVE across servers can hide the
   operation in a COPY/DELETE.

Yes, with emphasis on the word *client*, and with a suitably loose
definition of "hide" (i.e. there are no bindings or locks that will
expose the fraud :-).

   I am also assuming that locks aren't
   copied. Is this correct?


Received on Friday, 15 October 1999 12:33:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:18 UTC