RE: Locks, reservations, copies and moves

Actually, the present specification does address the interactions of LOCK, 
COPY, MOVE, and DELETE.  Section 5.2.4, Interaction With Other Methods, 
currently states:

5.2.4     Interaction with other Methods

            Only two methods, MOVE and DELETE, have side effects which
            involve locks. When a resource is moved, its lock SHOULD be
            moved with it. However this may not always be possible and
            there is currently no proposal to create a header which
            would specify that the lock request should fail if the
            resource's locks can not be maintained. A COPY MUST NOT copy
            any locks on the source resource over to the destination
            resource. Deleting a resource MUST remove all locks on the
            resource.

There has been some discussion concerning whether a lock should remain the 
same after a move (i.e., after the move you have the same lock on the same 
resource, only there is a new name for the resource).  My view is that 
since a move just renames the resource, the lock should still exist after 
the move.  However, this does disagree with the definition of move as a 
copy followed by a delete of the source, since copy should definitely not 
duplicate the lock.  My solution is to fudge this issue, and state that a 
move is a copy followed by a delete, except that the lock is transferred 
intact from the source to the destination.  While this gets the expected 
functionality (the lock follows the resource), it does create a certain 
inelegance in the definition of MOVE.

Also, where did you look for definitions of interactions between locks and 
other methods -- perhaps this section of the spec. should be located in a 
different part of the spec. (perhaps divided up and associated with COPY, 
MOVE, and DELETE?)

- Jim

On Thursday, August 28, 1997 5:30 PM, Dylan Barrell 
[SMTP:dbarrell@opentext.ch] wrote:
> There seems to be a bit of a hole in the draft in its current form with 
regard to locks and reservations which needs to be filled. We need to 
specify - either in the requirements document or in the spec - what happens 
to locks and reservations when a resource or collection of resources is 
copied and/or moved. The issue becomes problematic when you consider that 
the current definition of MOVE is a COPY followed by a DELETE and when you 
consider the issue of multi-resource locking.
>
> I don't know what the consensus is among the server folks but it seems to 
me that some of the server implementations might have problems dealing with 
these issues.
>
> The simplest solution seems to me to do the following
>
> 1. Disallow moving of locked or reserved resources (or at least resource 
locked as part of a multi.-resource lock)
> 2. Specifically state that the correct behaviour in the case of a COPY is 
to NOT copy the locks or reservations.
> 3. Change the definition of MOVE to be independent of COPY
>
> Cheers
> Dylan

Received on Friday, 29 August 1997 18:47:59 UTC