Re: Static depth locking

   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.

   I
   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.

   Client
   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?

Yes.

Cheers,
Geoff

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