W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

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

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>
Message-ID: <LOBBICBLDJIJHPNJFPOLEEEECMAA.mike@ammd.com.au>

> 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:01 GMT