RE: Bindings, Locks, and MOVE

<js>
Actually I was confused by thinking that a write lock would prevent a COPY
with Destination being the locked resource.  (So I thought that the COPY
step wouldn't be allowed to happen.)  But I see that the definition of write
lock doesn't address this case.

I do have trouble following your description of the fixup stage, though.  I
take it you don't think we face the awkward situation Kevin described, where
there end up being 2 resources where there used to be only one.  But how do
you avoid this?

Before the MOVE we have:

/a/b.html   /x/y.html         /c/d.html
    \         /                   |
     \       /                    |
      \     /                     |
         R                        S

and user1 has a lock on R through /a/b.html

Now user2 attempts to MOVE /c/d.html to /x/y.html.  First the binding y.html
is removed from collection /x/.  Then S is duplicated, say to S' and a new
binding y.html is created in /x/ to S'.  That's the COPY step.  At this
point we have:

/a/b.html     /x/y.html      /c/d.html
   |             |              |
   |             |              |
   R             S'             S

The DELETE step is to remove the binding d.html from /c/.  It doesn't look
as if there needs to be any fixup, but we do have the awkward result that we
now have 2 resources R and S' where there used to be just R.
</js>

<jlc>
I have to agree that I couldn't quite understand what GC meant by "fixup"
since it seemed none was necessary.

I also don't understand what you are saying about extra resources.

We began with R and S.   In a COPY we end with R, S, and S'.    That's one more
resource than we started with, but it's a "copy", so we should be surprised if
that means there's one more new resource in the world.  It's the same thing that
we see when we go to a xerox/copy (:-))  machine.  We walk go there with one
copy of a document and walk away with two.

As for the MOVE, we start with two resources and end with two.  No surprise once
again.

The only surprise might be that some folks might intuitively think of a
MOVE/COPY as replacing of the destination's state, but since we say it deletes
the destination first, what we see isn't a change of state... but a change of
resource at the destination.
</jlc>

Received on Wednesday, 15 September 1999 14:47:39 UTC