RE: Locking: Implementation Considerations

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>

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.

<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

Received on Thursday, 5 August 1999 17:42:17 UTC