RE: What is left after LOCK/UNLOCK on null resource?

   From: Michael Leditschke [mailto:mike@ammd.com.au]

   > The new process needs to obtain its own (new) lock.  The old
   > lock is cleaned up by a timeout, or if allowed by the server,
   > the new process can clean up the old lock with an UNLOCK.
   > The new process shouldn't "reuse" the old lock, unless you have
   > some way of guaranteeing that two processes cannot both reuse the
   > old lock at the same time.

   And if the lock were exclusive with an infinite timeout? A lock
   on an already locked resource will fail. Isn't lock re-use the
   only option apart from Administrator intervention?

We need to carefully distinguish "re-using" the old lock,
from "deleting" (i.e. unlocking) the old lock.  It is reasonable
to have another process unlock a resource, because if the
other process holding that lock token is still alive, and
tries an update with the old lock, the update will fail
(although the old process is now stuck with a merge situation,
which is what the lock was being used to prevent in the
first place ... if it just wanted overwrite protection, it
could have just used Etags).  It is never reasonable to
have a process re-use a lock token allocated by another process
(i.e. use that lock token in a PUT or PROPPATCH).

I believe the "right" answer is that a server should never
allow an infinite timeout on a lock.

   Is it fair to say the locking model is more oriented to 
   transient locking rather than long term locking?

Yes.  For "long term locking", you'd want to use the
checkout/checkin model provided by the DeltaV WebDAV extensions.

Cheers,
Geoff

Received on Thursday, 5 September 2002 07:50:56 UTC