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

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 6 Sep 2002 16:20:57 -0400

From: Jim Whitehead [mailto:[email-masked]]

   > ... an exclusive lock token should
   > only be used in an update request (PUT/PROPPATCH) by the process
   > that took out the lock originally.  (Note that I do not at all
   > object to another process UNLOCK'ing a lock created by another
   > process).

   If you're editing a document, and your machine crashes, you would
   like to reboot your machine, and then restart your authoring
   application to continue editing the same document.

Agreed.

   This is strictly a different operating system process than the one
   that took out the lock, yet this new process should be able to
   assume the existing lock.

That is the premise you need to prove, not a statement you can assume
to be true.  In particular, since you cannot in general know whether
or not the original process is gone or simply inactive (even if the user
believes it has), a client cannot safely "assume" the existing lock.

   Alternatives, such as the Office model where locks last for only two
   minutes, allow the lock to timeout while the machine is being rebooted,
and
   hence it's possible for the lock to be grabbed by another person after it
   has expired.

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).

   Social conventions surrounding turn-taking in collaborative
   authoring tend to make it so this doesn't actually happen, but the
   possibility does exist.

It doesn't make sense to introduce a serious problem (multiple
processes using the same lock token, causing overwrites to occur) to
handle an unlikely event, especially when there are safer ways to deal
with the problem (described above).

   It is also possible to require the new editor instance to
   explicitly remove the existing lock, then take out a new one, but
   to do this requires the same information you'd need to assume the
   existing lock, and still provides a small window of lock-grabbing
   vulnerability.

But it prevents overwrite problem, which is the whole point
of locking.  Why would you want to introduce a serious flaw in
the protocol (i.e. risk of overwrite), in order to avoid a
low-likelihood event that has a safe alternative solution?

   > If you want to allow multiple processes to effectively "share"
   > a lock token, the protocol has defined shared locks.

   Shared locks don't strike me as being appropriate for this case,
   since you'd have two shared locks, each owned by the same person
   (DAV doesn't have a way to explicitly represent the process taking
   out a lock).

I agree that shared locks aren't an appropriate way to get an
exclusive lock, but "assuming" an existing exclusive lock is even
worse, since at least a shared lock makes it clear that you are not
expecting the protocol to protect you against overwrites, while
a client should be able to ignore overwrite issues while they
hold and use an exclusive lock token.

Cheers,
Geoff

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 6 Sep 2002 14:56:08 -0700

> their next attempt to update (their lock token will no longer be

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