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

> 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