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

> But until Dan (or someone) has published a convincing rationale
> for having multiple processes reuse the lock token for an exclusive
> lock,  I will continue to maintain that 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. 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.

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. Social conventions surrounding turn-taking in collaborative
authoring tend to make it so this doesn't actually happen, but the
possibility does exist.

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.

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

- Jim

Received on Thursday, 5 September 2002 18:49:03 UTC