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

   From: "Eric Sedlar" <esedlar@us.oracle.com>

   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. 

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

   ----- Original Message -----
   From: <ccjason@us.ibm.com>
   To: "Eric Sedlar" <esedlar@us.oracle.com>
   Cc: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>;
   <w3c-dist-auth@w3.org>
   Sent: Thursday, January 13, 2000 2:32 PM
   Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)


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

Received on Friday, 14 January 2000 09:28:35 UTC