RE: RFC-2518 LOCK-TOKEN: header

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.

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

- Jim

Received on Tuesday, 25 January 2000 18:38:28 UTC