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: Lisa Dusseault <lisa@xythos.com>
Date: Fri, 6 Sep 2002 14:56:08 -0700
To: "'Clemm, Geoff'" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Message-ID: <000e01c255f0$361a4b00$29c4fea9@xythoslap>

> The result of you "losing" the lock are far less serious than the
> results of having two processes use the same lock (which is the risk
> you take by "assuming" an existing lock).  If someone else has taken
> out a lock (not all that likely in the first place), you immediately
> know what has happened, and can negotiate with the other lock holder
> if your authoring need is more urgent.  Or you might simply cancel
> their lock with an unlock, and take out a new lock of your own if you
> need to preempt their lock, and they will know this has happened on
> their next attempt to update (their lock token will no longer be
> valid).

Geoff's right. If two processes are using the same lock, both must be
aware of this, and they need *another* way of communicating which is
expected to change the resource when.  Otherwise, the "lost update"
problem isn't solved at all, you've found a work-around for the
solution!

Note that whether or not a lock is used by a single process, shared
among cooperating processes, or lost during a reboot or other timeout,
ETags STRONGLY SHOULD be used to check if the resource is unchanged.
Note what the ETag is whenever a GET is used, and cache that
(persistently, so that even if the computer crashes and the lock is
lost, the ETag should still be available).  Then when doing a PUT, use
the If-Match header to make sure that the ETag is still the same. 

So:
 - most of the time you shouldn't be losing locks accidentally;
 - most of the time when you do lose a lock accidentally you can check
the ETag to make sure that you can relock without having to consult the
user;

 - In the rare cases when you do lose a lock and the ETag has changed,
user intervention is required to make sure that content is not being
overwritten;
 - In the rare case when you do lose a lock and the resource has now
been locked by somebody else, it's necessary to tell the user their file
is not available for writing. 

Lisa
Received on Friday, 6 September 2002 17:56:43 GMT

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