- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 6 Sep 2002 16:20:57 -0400
- To: w3c-dist-auth@w3.org
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