- From: Michael Leditschke <mike@ammd.com.au>
- Date: Thu, 5 Sep 2002 21:57:18 +1000
- To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
> 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 > > Thanks for the clarification. Regards Michael
Received on Thursday, 5 September 2002 07:57:25 UTC