Re: RFC-2518 LOCK-TOKEN: header

Ah, good, we've flushed out an author (:-).

   From: Jim Whitehead <ejw@ics.uci.edu>

   Bill Carpenter writes:
   > This doesn't address other reasons for doing unambiguous lock
   > discovery.  It leaves aside such rainy day scenarios as "oops, my
   > application just crashed (et seq :-))" and "I guess I'll go home for
   > the night and work on this".

   When dealing with exclusive locks, the lack of owner information is more an
   inconvenience than a   problem in the situations you mention. A client can
   retrieve the lock token by performing lock discovery, and then assume it
   belongs to that client.   The server will let the client know if this isn't
   the case.  To prevent a user from doing too much work before they discover
   the lock token doesn't belong to them, the application should pop up a
   dialog letting the user know what happened, and then try to write a dummy
   property using PROPPATCH (or some other simple, easy-to-undo write
   operation), and see if the method succeeds.

The whole point of having a lock token is so that you can handle the
case where multiple clients are active for a single principal.  If you
are going to encourage a clients to use a lock token it did not obtain
with a LOCK, the lock token is totally pointless, and should be
removed from the protocol.

   > gmc> So a client should always get its own lock token, not appropriate
   > gmc> an existing one.  If a resource is already exclusively locked, it
   > gmc> first will need to UNLOCK the resource.  This then guarantees
   > gmc> that if the other client (that issued the LOCK request) is still
   > gmc> around, it will notice the "cancellation" by the failure of its
   > gmc> next update request.
   >
   > This technique also opens a (probably very small) window wherein
   > someone else could grab the lock.  (Such events are not always a
   > matter of competition.  You could be under the impression that your
   > co-author was going to release the LOCK when s/he was done and it was
   > your turn.)

   So, I'm not as opposed to grabbing an existing lock token as Geoff is.  If a
   client does seize a lock token, the application should inform the user of
   this.

And would this message be something like "as your client, I decided
overwrite protection is not needed, so I'm just going to use some
other client's lock token"? (:-)

On the other hand, you can UNLOCK the resource and get your own lock,
ensuring that any still alive clients will know that this happened when
they next try to do an update.  The only benefit of the former approach
is that it removes a miniscule window for some other client to come in
and get a lock (where that client has just as much a right to author that
resource as you do).  Seems like you are throwing away the only value
of token based locking in return for a very unlikely and even arguably
"unfair" benefit.

I still may be missing something, but I still don't think so (:-).

Cheers,
Geoff

Received on Tuesday, 25 January 2000 19:27:38 UTC