Re: Crossserver ops and lock token swapping.

   From: ccjason@us.ibm.com

   <jlc/> ... MOVE just changes some of the URI's at which resources are
   accessable.  In this case the resource(s) is now accessable via a URI
   on another server.  ... In order to achieve this, we implicitly
   require (except for special cases) that server pairs cooperate on
   bindings... and therefore locks since a locked resource can be
   accessed via a URI on either machine.

   <gmc/>  I agree with all this, except for the "except for special cases".
   What did you have in mind here?  Either the server pairs cooperate on
   bindings so that bindings semantics is maintained, or they must fail
   the BIND or MOVE request that would have created the cross server binding.

   <jlc/>I don't remember what I meant before.  I'm guessing that I was
   thinking of the limited situation that I outlined in my note to Greg.
   The situation where there are no locks on the source and only single
   bindings.  I think we couldn't protest very vigorously if in special
   cases like this, servers (that might not even support bindings) tried
   to carry out the move using PUT/PROPPATCH/DELETE.

I wouldn't call that a special case.  It's just a case where it's very
easy for the two servers to cooperate on the bindings because as a result
of the MOVE, all bindings (i.e. the single binding) live on just one
server.

   <jlc/> These are really simple servers with simple
   mappings.  One mapping per resource.  But one wants to move resources
   between these servers.  Nothing fancy.  Just move them.  Can we
   actually expect unsophisticated servers to actually support locks
   generated by other servers?  So this suggests...

   <jlc/> 
   1) MOVE does not move locks from source to destination in any sense.
   (But this breaks model of resource is what is locked.)

   <gmc/> I agree.  Unless we want to define two different MOVE
   protocols, the protocol has to make sense not only for simple servers,
   but also servers that do support multiple bindings to a resource.  And
   deleting the locks from the source of the copy does not work if there
   are multiple bindings to a resource that still expect it to be locked.

   <jlc/>I'm glad you agree, but I'm not sure with what you are agreeing.
   Let me guess that you are agreeing with the, "but this breaks...", so
   you are disagreeing with a special case that says in some cases locks
   don't move with the resource.

<gmc/> Yup. (I was agreeing with your "But..." statement).

   <jlc/> -- Or perhaps you're agreeing that locks
   shouldn't move with the resource at all? 

<gmc/> Nope.  (I believe locks should move with the MOVE).

   <johns/> It occurs to me that the biggest reason you'd want to MOVE the
   lock is because you want to keep control over the resource in the new
   location.  Couldn't you do that by locking the destination and then
   MOVEing the resource?

   <gmc/> Good point.  I may have to withdraw my objection to the null-resource
   lock, since only the null-resource lock survives a MOVE.

   <jlc/> Geoff, what is it that you are withdrawing?  Please clarify.

<gmc/> I was contemplating withdrawing my objection to a null-resource
lock (in an earlier thread, I proposed that we get rid of null
resource locking).  I had asked what you can do with a null-resource
lock that you can't do with a lock on a dummy resource created by the
client.  John's suggestion was an example of something that should work
with a null-resource lock but that shouldn't work with a lock on a
regular resource (the lock on a regular resource at the destination of
a MOVE should be deleted by MOVE).

Cheers,
Geoff

Received on Saturday, 11 September 1999 23:22:09 UTC