Re: Bindings, Locks, and MOVE

Slein, Judith A wrote:
> 
> The intention is that if a resource is copied or moved into a tree that is
> locked, the lock on the tree remains in force.
> 
> We didn't discuss the case where you are doing a MOVE, and the resource
> being moved is locked, and it is being moved into a collection that is
> locked.  The lock on the collection will certainly stay in force, but we
> need to decide whether the lock on the resource being MOVEd will be lost or
> whether the MOVE will fail.  I guess my own opinion is that the MOVE should
> fail, since that maintains a consistent position that the state of a MOVEd
> resource should be unaffected by the move; if its lock state would have to
> be changed, the move should fail.

There is a third case: allow the move. How about this: allow the MOVE,
the resource then falls under the Destination lock, the source is now in
a lock-null state.

Therefore, the user does *not* lose any locks, the MOVE is completed,
and this scenario actually provides a way to do a "safe" MOVE. If the
user could not lock both ends, then you have a race condition. Further,
making the user lock the source "one level up" so that the lock wouldn't
move with the resource just feels like a hack.

If you are MOVEing a collection and there is a lock on one of the
collection members, then the move should fail if there is an
incompatible lock (e.g. exclusive and not the same lock) at the
destination.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Received on Wednesday, 8 September 1999 16:17:37 UTC