Re: DELETE leaving a lock-null resource; was LOCK Scenarios

   From: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>

   > Using the updated proposal where a process gets back a 302 when it
   > tries to access a locked resource that has moved, word will have to
   > update its path to the document the next time it accesses it for read
   > or write.  When it does so, the user will know to look
   > at the new place in a different process.

   How long do you expect the original resource to remember the forwarding
   information?

In an implementation, it often isn't the resource that is remembering
the forwarding information, but rather some locking authority.  This is
true for many WebDAV implementations (although certainly not all).
The locking authority must maintain any forwarding information
for the lifetime of the lock.

   So if you move foo/bar to foo/baz and someone else creates a
   new resource at foo/bar then the forwarding from foo/bar to foo/baz will be
   destroyed. These are file systems, they don't have long memories.

If an implementation cannot maintain forwarding information, then it must
fail the move (with a "locked" status).

   Also, how do you think the UI in Hiro's word processor is going to tell him
   about the name change? "Dear Hiro, someone decided to move your file for
   you, it now lives at the following name."   I can't ship that product,
   my users would revolt.

If Hiro's word processor is using HTTP (the premise of WebDAV), it had better
be prepared to handle a 302.

   > Probably somebody who had a good reason do so (perhaps fixing a bad
   > copyright statement in her document).  In either case, there is no
   > lost update problem, since she has no pending updates to the document
   > (except for those only in her head, which we can't take responsibility
   > for :-).

   The only problem is that her document has mysteriously disappeared, even
   though she locked it. Admittedly this can happen anyway if the admin
   overrides her lock but that is a very rare circumstance and enough of a
   disaster that the admin would be expected to send e-mail out to those
   affected. The same would not be true here. If Joe comes along and moves the
   entire directory and isn't aware that Irit had a locked file he would never
   know he should tell Irit.

The lock is there, and Joe could easily notify all the lock holders (assuming
the locks hold principal information, as is recommended).  In fact, if he
had a good client, it could largely automate the notification process.

   So when Irit comes back her file is gone and she
   has no idea what has happened. Even if Joe knew, it wouldn't be sufficient.
   Irit wants her stuff staying where it is, that is why she took out the lock.

And I want to put red lights on all cross-roads of all the intersections
on my way to work (:-).  But I'm not allowed to do that because it interferes
with everybody else's commute.  Just a silly analogy, but not too
far off the mark, I believe.

   You seem to believe that locks are just there to protect content. That
   simply isn't true. Locks are there to control the name for it is the name
   which gives access to everything. By controlling the name you control where
   the name can be moved as well as who can access the content pointed to by
   the name. Locks are more about names then they are about content.

I think we agree that locks are there to prevent the lost update
problem (i.e. protecting content).  It is an interesting question as
to whether they are appropriate for preventing other problems, and if
so, how they are best used to do so.  I believe that locks are useful
for keeping a handle on where a locked resource is located, but that a
server should be able to allow the move and return a 302, if it wants
to maximize parallel work.  A server can also just fail a moves if it
cannot track the movement of a locked resource.

   In our experience the over whelming majority of documents are one user at a
   time. That is, one user edits and then hands over control to another user.
   Locks prevent control from being transferred prematurely. They also prevent
   unwanted changes to shared namespaces. While documents are often single
   user, namespaces are often shared. 

Yes, it is the shared nature of namespaces that causes me to resist
requiring anything like a "namespace lock".  To say that a server can
do such a lock if that's the best it can to, then that's fine.  But
to say that all servers must act that way leaves out a useful
alternative, namely, using 302's to let a client know the new location
of their locked resource.  Since a web client needs to know
how to deal with 302's anyway, I believe there is little or no
additional cost to clients.

Cheers,
Geoff

Received on Saturday, 23 October 1999 20:11:23 UTC