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

From: [email-masked]
Date: Thu, 13 Jan 2000 17:32:36 -0500

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.

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.

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.

Jason.

---

From: "Eric Sedlar" <[email-masked]>
Date: Fri, 14 Jan 2000 01:58:38 -0800

This is what is supposed to happen when you lock a collection--you lock all
of the names within it, probably given that you are going to do a
reorganization.  For you to demonstrate that this is a problem, give a
scenario where a versioning-unaware application is going to lock a
collection.

--Eric

----- Original Message -----
From: <[email-masked]>
To: "Eric Sedlar" <[email-masked]>
Cc: "Geoffrey M. Clemm" <[email-masked]>;
<[email-masked]>
Sent: Thursday, January 13, 2000 2:32 PM
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 14 Jan 2000 09:09:33 -0500

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

   From: [email-masked]

   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.

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

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 14 Jan 2000 09:28:32 -0500

From: "Eric Sedlar" <[email-masked]>

   reorganization. 

Here I believe Eric is assuming the lock on /a/b was a depth:infinity
lock (correct default 2518 behavior), in which case one would expect
a conflict between an exclusive depth:infinity lock on /a/b and an
exclusive lock on /a/b/c/d.html (in my response, I postulated a
depth:0 lock on /a/b).

Currently, GULP would not detect this conflict until someone tried to
create a resource named /a/b/c/d.html, at which point the exclusive
lock conflict would prevent the creation of that resource.

We could either just say that it is OK to defer the conflict detection
until resource creation time, or we could make GULP smarter about
detecting exclusive lock conflicts on resources that do not yet exist.
The downside of doing so is that it adds complexity to the
specification.  I could go either way ... does anyone have a strong
preference?  I'll go ahead and add clause to the exclusive lock
conflict rule to handle this, and we can always rip it out if it
doesn't seem worth the added complexity.

Cheers,
Geoff