- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 5 Sep 2002 07:50:25 -0400
- To: w3c-dist-auth@w3.org
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