RE: Notes from DAV meeting

   From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com]

   > From: Clemm, Geoff [mailto:gclemm@rational.com]
   > A client holding a lock already has to deal with locks being lost
   > through timeouts.  Allowing another client to effectively force the
   > timeout is a valuable feature that does not increase the complexity of
   > the locking client.  A server can use access control to control what
   > users have permission to force the timeout.

   Supposing the server only supported infinite timed locks (which is
   allowed) and therefore lost locks through timeouts are not an
   issue. You've just bypassed the lock mechanism as we know it. In my
   crude example, what is the original lock creator suppose to do ?

I would strongly advise all client writer to expect timeouts
(assuming you want to interoperate with existing implementations,
such as those provided by Microsoft).  If your lock no longer
exists (either because of a timeout or an explicit unlock by
another client), then your client is responsible for letting the
user know that a write will possibly overwrite subsequent changes.
If the resource is locked by another client, your client should
give the user the option to "save as" at a different URL.  The user
can then look at the two resources (perhaps with the aid of a merge
tool, but often not) to decide whether to merge or just overwrite
the current resource.  In order to update the original resource,
the user can wait until it is unlocked, or if it has sufficient
privileges, it can "steal" the resource back (by unlocking and
then taking out its own lock).

The bottom line is that clients die and leave locks in place on
critical resources.  A server that allows no form of automatic
intervention in this case (either with automatic timeouts, or
with explicit unlock overrides) is unlikely to become very popular.

Cheers,
Geoff

Received on Wednesday, 15 August 2001 13:07:53 UTC