Re: checkout/checkin/uncheckout vs. lock/unlock
David G. Durand (dgd@cs.bu.edu)
Mon, 30 Nov 1998 22:36:22 -0400
Message-Id: <v04011702b288fe33d81b@[24.0.249.126]>
In-Reply-To: <4FD6422BE942D111908D00805F3158DF0A757934@RED-MSG-52>
Date: Mon, 30 Nov 1998 22:36:22 -0400
To: Chris Kaler <ckaler@microsoft.com>,
"'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>,
From: "David G. Durand" <dgd@cs.bu.edu>
Subject: RE: checkout/checkin/uncheckout vs. lock/unlock
At 3:39 PM -0400 11/30/98, Chris Kaler wrote:
>My idea was that if we make them the same method, you remove much of the
>confusion. A checkout is, in many ways, a lock. You "checkout" either
>shared or exclusive. That is the same as a lock. The only difference is
>that you have a working resource.
Well, the working resource is the important thing. Locking (in the sense of
blocking some operations) is purely optional depending on a server's
desired policy. This seems like two things glommed together into one method
to me.
> - What if you want to leave the working resource available
>for anyone
> to modify? In what sense have you created a lock?
>
>You make it shared and everything is fine
>
> - When you checkin a resource, you have now made an
>immutable revision.
> In what sense have you "unlocked" anything?
>
>I argue that a checkout is an implicit lock against the resource and by
>checking in, you have removed that lock.
Since the resource was not modifiable, it's a funny kind of lock. If the
access is non-exclusive (anyone else can do a checkout as well), it's not
even a lock in the sense that it blocks other checkout operations. In fact,
in that case, it's not very lock-like at all, since no operation is blocked
by it.
You didn't actually answer the objections either, but just repeated your
assertion. Maybe my verbose statement of why it's not a lock will give you
a better handle for arguing your point.
So I think that the notion is rather confusing. Servers that don't offer
locking (are then required to supply "non-exclusive locks", and track their
IDs, when in fact they need no such objects or functions... While I approve
of complexity in the server more than complexity in the client, it seems to
me that this makes life harder for clients as well...
> - Converely, when you "uncheckout" a working resource, you
>delete it.
> In what sense have you "locked" anything?
>
>This is another reason why I like the LOCK method. In many systems,
>explicit locking is used. PUTs with require the lock-id to be specified.
>By tieing the two together, clients don't need to worry (or think) abou the
>"working resource". They do their PUT to the versioned resource and specify
>the checkout lock. The server validates the lock and updates the working
>resource. I actually think this is much easier for the client than having
>to track the versioned resource, the working resource, and the lock-id.
>Less information, consistent protocol.
You seem to making a round-trips argument. In my other message, I suggest
that this could be optimized without merging the two methods. It always
seemed reasonable to me that a checkout _might_ create a lock (since that's
the way many systems work). Requiring that a lock be created seems a
different kettle of fish (since other systems don't have the notion of
locking).
> - When you "checkout" a versioned resource, you create a new
>(working)
> resource. A "lock" is not something you expect to create a
>new resource.
>
>But many (most) checkouts result in the versioned resource being locked in
>some way. So this approach lessens the round-trips and the information the
>client must track and keeps the protocol almost exactly the same as
>non-versioning.
This merger would be a lot more appealing if the semantics of "checkout
locks" really matched the semantics of other locks: since a "non-exclusive
checkout lock" is actually equivalent to no locking at all, this strikes me
as more confusing than useful, especially since the extra round trip can be
eliminated _without_ merging the concepts of checkout and lock for
everybody.
-- David
_________________________________________
David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
--------------------------------------------\ http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW \__________________________