- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Fri, 14 Jan 2000 09:28:32 -0500
- To: w3c-dist-auth@w3.org
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