Re: Locking: Implementation Considerations

I'd be quite happy to dump Depth:infinity locks from mod_dav. There is a lot
of code in there to deal with those things. Keith Wannamaker did a good job
writing it all and may be sad to see it go :-), but in the best interest of
things... I'm game.

Cheers,
-g

----- Original Message -----
From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
To: <JSlein@crt.xerox.com>
Cc: <w3c-dist-auth@w3.org>
Sent: Wednesday, August 18, 1999 2:33 PM
Subject: Re: Locking: Implementation Considerations


> I believe that in the context of advanced collections (multiple
> bindings to a single resource) and versioning (multiple workspaces
> providing different views of the same URL hierarchy), Depth:infinity
> locking will be undesireable both for clients (does the wrong thing)
> and for servers (too expensive to implement).
>
> >From the server side, Judy has described the difficulty of
> implementing Depth:infinity locking in the context of multiple
> bindings.  With the introduction of versioning, with rule-based
> selection of each versioned collection on the URL path to a versioned
> resource, the cost of maintaining Depth:infinity locking increases to
> an even more unacceptable level.
>
> >From the client side, a Depth:infinity write lock on a collection will
> lock all properties of all resources in the workspace's view of that
> collection.  This effectively prevents labeling and creating
> successors of those resources by another user in *any* workspace,
> effectively eliminating many critical aspects parallel development.
>
> In contrast, Depth:0 locks work just fine, since normally you would apply
> them only to the working resources you have checked out, and those are
> not visible in other workspaces anyway.
>
> So what conclusion can one draw from all this?
>
> One possibility is to say that locking is largely unneccessary in the
> presence of versioning (after all, everything is read-only unless you
> explicitly check it out into your workspace), so versioning servers
> just won't bother with locking at all.  This would have an unfortunate
> interoperability result on Class-2 clients try to work with versioning
> servers.
>
> Another possibility is to downgrade Depth:infinity locking to a MAY,
> thereby warning clients that they are likely to find this not supported,
> and to turn the default lock into Depth:0, instead of Depth:infinity.
> The latter will cause an interoperability issue with existing class-2
> servers, but since there aren't many of those yet, if we move fast, this
> would probably be OK.
>
> Cheers,
> Geoff
>
>    From: "Slein, Judith A" <JSlein@crt.xerox.com>
>    Date: Thu, 5 Aug 1999 17:13:56 -0400
>    Mime-Version: 1.0
>    X-Mailer: Internet Mail Service (5.5.2448.0)
>    charset="iso-8859-1"
>    Resent-From: w3c-dist-auth@w3.org
>    X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3120
>    X-Loop: w3c-dist-auth@w3.org
>    Sender: w3c-dist-auth-request@w3.org
>    Resent-Sender: w3c-dist-auth-request@w3.org
>    Precedence: list
>    Content-Type: text/plain;
>    charset="iso-8859-1"
>    Content-Length: 1787
>
>    One of the issues we've been talking about is what should happen if you
MOVE
>    a resource into a locked collection.  What lock should be on the
resource
>    after the MOVE?
>
>    I think the question is whether collection locks with Depth: infinity
should
>    be inherited statically or dynamically.  Should a collection lock with
>    Depth: infinity affect just those resources that are in the collection
at
>    the time the lock is created (static inheritance), or should the lock
affect
>    whatever resources come into the collection while it is in force (and
stop
>    applying to any resources that are removed from the collection)
(dynamic
>    inheritance)?
>
>    Static inheritance suggests that the lock would be maintained on the
>    collection and also maintained on each resource in the collection to
depth
>    infinity.  It would be painful to create this lock, and painful to
remove
>    it, and while it is in force it would be necessary to keep track of the
>    MOVEs out of the collection in order to be able to remove the lock
correctly
>    in the end.  However, if every lock is maintained on each resource it
>    affects, it is easy to tell whether a given resource is locked.
>
>    Dynamic inheritance suggests that the lock would be maintained only on
the
>    collection.  It is easy to create and remove such a lock.  But it is
>    difficult to tell whether any given resource is locked when someone
attempts
>    a PUT, MOVE, etc.  Especially once the BIND method is available, you
would
>    have to trace from the resource in question upward through all the
bindings
>    on all the collections in the hierarchy to find out whether the
resource is
>    locked.
>
>    Currently, section 7.7 of RFC 2518 requires dynamic inheritance of
locks.

Received on Wednesday, 18 August 1999 18:47:25 UTC