Subject: Locking: Implementation Considerations

From: "Slein, Judith A" <[email-masked]>
Date: Thu, 5 Aug 1999 17:13:56 -0400

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.

-- Judy

Judith A. Slein
Xerox Corporation
[email-masked]
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

---

From: "Kevin Wiggen" <[email-masked]>
Date: Thu, 5 Aug 1999 14:37:26 -0700

My notes in <KW> tags...

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?
<KW>
As you mention below section 7.7 of the spec says the new resource is now
locked by the lock on the collection IF the depth = infinity
</KW>

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)?
<KW> I think its a mixture.  The lock should be statically placed on the
resources when the lock is made.  The lock on the file should be removed if
a lock is MOVED out of the locked collection, but the rest of the resources
should remain locked.  If a new resource is MOVED into the locked
collection, it then needs to take on the lock.

Whether you keep track of the lock on each file, or walk the tree every
time, is an implementation issue.  I think that it should work like above..
</KW>

<KW>  Painful to create, yes, necessary, yes.  You already need to look at
each resource in the collection to determine if it is already locked.  It is
possible for some resource 10 collections deep to be locked and thus the
lock request should fail.
</KW>

I will send my thoughts on your examples (thanks for writing them up) soon.

Kevin

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 18 Aug 1999 17:33:57 -0400

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" <[email-masked]>
   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: [email-masked]
   X-Mailing-List: <[email-masked]> archive/latest/3120
   X-Loop: [email-masked]
   Sender: [email-masked]
   Resent-Sender: [email-masked]
   Precedence: list
   Content-Type: text/plain;
	   charset="iso-8859-1"
   Content-Length: 1787

---

From: "Greg Stein" <[email-masked]>
Date: Wed, 18 Aug 1999 15:45:08 -0700

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