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

   From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]

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

Received on Friday, 6 September 2002 16:21:28 UTC