Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)

I'll flesh out Jason's example with the resulting lock state (as defined
by GULP).

   From: ccjason@us.ibm.com

   Ah... Eric's note brings up another possibility.  It might be a red
   herring, but as Geoff's proposal is currently written (and Eric's too
   I think) it still is a possibly unexpected behavior.

   User B  locks /a/b/ exclusively.

Suppose / does not identify a WebDAV resource, but /a does.
Suppose that /a/b/c identifies a resource, but /a/b/c/d.html does not.

Then the user B lock results in a ["b/.", "tok153"] lock on /a
and a [".", "tok153"] lock on /a/b.  All locks with token "tok153"
have exclusive scope.  Although according to 2518, a lock is by
default depth:infinity (which I believe is broken, and should be
replaced by a default depth of zero), I believe Jason intended a
depth:0 lock, so we'll postulate that all locks with token "tok153"
are depth:0.

   User D tries to do a shared lock on /a/b/c/d.html but fails because in
   the proposal that will also create a lock (or will it?) on /a/b/ which
   already has an exclusive lock on it.

If user D's request succeeded, it would add a ["b/c/d.html/.",
"tok192"] lock to /a and a ["c/d.html/.", "tok192"] lock on /a/b and a
["d.html/.", "tok192"] lock on /a/b/c.  Since none of these locks
conflict with any of the existing locks, user D's request succeeds.
In particular, the ["b/c/d.html/.", "tok192"] lock on /a has a
different target from the ["b/.", "tok153"] lock on /a, so there is no
conflict there.

   I'm not saying this is good or bad.  I'm just pointing it out as what
   sounds like a difference in the recent proposals relative to what we
   were proposing a month or more ago.

I don't think it is acceptable for the exclusive lock on /a/b to conflict
with an exclusive lock on /a/b/c/d.html (so it's a good thing GULP allows
it :-).

Cheers,
Geoff

Received on Friday, 14 January 2000 09:09:39 UTC