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                    \__________________________