Re: checkout/checkin/uncheckout vs. lock/unlock

Chris Kaler (
Mon, 30 Nov 1998 20:47:16 -0800

Message-ID: <4FD6422BE942D111908D00805F3158DF0A75794A@RED-MSG-52>
From: Chris Kaler <>
To: "'David G. Durand'" <>,
Date: Mon, 30 Nov 1998 20:47:16 -0800
Subject: RE: checkout/checkin/uncheckout vs. lock/unlock

There are several types of locks.  Shared, Advisory, and Exclusive.  I
cannot see why you would (in most cases) want to check out a resource
without taking one of these locks.  In a collaboration world, you want to
know who else is working on the document.  Locks provide an existing
mechanism to discover and manage this information.

Personally, I don't like the idea of method side-effects: "BTW this
operation also locked something."  

Hopefully we can continue this discussion on Wed.


		-----Original Message-----
		From:	David G. Durand []
		Sent:	Monday, November 30, 1998 6:00 PM
		Subject:	RE: checkout/checkin/uncheckout vs.

		>I'd like to hear who these people are.  Most people I talk
to either do
		>implicit versioning (don't want to be bothered by it, just
make it happen)
		>or use exclusive versioning (which requires locking).  So I
find this
		>requirement confusing.  Not to mean its invalid, I've just
never heard it

		I've certainly mentioned it almost every time I open my
mouth. It's one of
		my little obsessions.

		If you're supporting tight collaboration, you may prefer to
		(temporary) divergence in document state in order to achieve
		progress (automatic forking is one way to avoid locking).
Similarly, if you
		are relying on merge tools (like the CVS model for software
		control) you may prefer to create a conflict that can be
resolved later,
		rather than block the human.

		My database teacher always used to point out that some
actions (like making
		a report to a terminal, or starting a user interaction)
		commitcommit a transaction because you "can't abort the
user." Similarly in
		editing, you may not want to lock out a user, but that
doesn't mean that
		you just want to lose information either.

		Separating checkout (reservation, as we called it in the
		document) from locking makes this distinction clear. It also
separates the
		"transaction management" function of a checkout (maintaining
whatever state
		the server may need to maintain) from the locking function:
(which enforces
		access conditions on a resource).

		One thing we _could have_ (I'm not advocating this, but some
might) is a
		response that would let a server tell a client that a lock
has been
		assigned as a result of the checkout operation. Servers that
		locking all the time would then be able to inform clients of
the needed
		lock ID. This makes the protocol more complex, but reduces
the round trips
		for a lock/checkout pair.

		Those of you who are building servers that enforce this kind
of locking
		probably know more than I do about whether that's a needed

		  -- David
		David Durand      \
		Boston University Computer Science        \  Sr. Analyst   \  Dynamic
		MAPA: mapping for the WWW