Locks and Concurrency

[Christopher Browne]

On Mon, 01 Jan 2001 18:07:01 EST, the world broke into rejoicing as
David Merrill <dmerrill@lupercalia.net>  said:
> On Sat, Dec 30, 2000 at 01:04:01AM -0600, linas@linas.org wrote:
> > 
> > It's been rumoured that David Merrill said:
> > > 
> > > Option 1, no concurrent edits allowed:
> > > 
> > > client 1 -> server "I want to edit record 1"
> > > server -> client 1 "OK"
> > > 
> > > client 2 -> server "I want to edit record 1"
> > > server -> client 2 "NO"
> > > 
> > > Only one user can edit at a time. Easy to implement; can be
> > > frustrating to the user.
> > 
> > esp. if user 1 leaves for lunch, or ^C's out.
> 
> Oh yeah. Shudders. 

The "easy" way to implement this is to implement a lock manager as
an available system service.  [If there got to be a lot of locks, 
it might be sensible to spawn a separate process; probably not a
critical matter right now...]

The lock manager would provide atomic access to a "lock" table, which
might contain something like:

Object ID    Session ID   
----------------------------------
 Txn:1234        cbbrowne:2
 Txn:4567        cbbrowne:2
 Acc:1234        dcbrowne:1
 Txn:4282        dcbrowne:2

The interpretation of the above is that there are 4 outstanding locks,
3 on transactions, and 1 on an account, across 3 different user sessions.

Supposing cbbrowne:2 goes out for lunch, and the dcbrowne:2 session tries
to modify transaction 4567 [by the way, the ID probably should be a GUID],
then should be straightforward for the system to report back with a 
dialog indicating:

   +----------------------------------------+
   |    Transaction    4567  is locked by   |
   |    user cbbrowne, session #2.          |
   |    That session has been idle since    | 
   |    2001/01/02 12:37 CST                |
   |                                        |
   |    Options:                            |
   |       Abort?    Retry?   Steal Lock?   |
   |       Send Nastygram to cbbrowne?      |
   +----------------------------------------+

I leave 4 options in there for "what to do;" if a session has died,
it should be perfectly reasonable to clear out corresponding locks,
whether automagically or one by one.  I suspect that the latter may
be preferred, after all, if a session crashed while updates were 
in progress, it might be a nice idea for the system to let the gentle
user know that _something_ is perhaps amiss.

Note:  The above dialog and table are somewhat derivative of existing
systems:
  a) SAP R/3 does transaction locking via having a "lock manager" and 
     stores locks in "tabular" form.  It does not offer the notion of
     having locks associated visibly with sessions, but rather with
     users.

  b) The option of "stealing the lock" is derivative of the way Emacs
     handles multiple users working with RCS files.  

Note that this approach allows the policy on what to do in case of
"deadlock" to be treated as a sort of dynamic condition.  

The set of reasonable options are likely:
a) Abort
b) Retry [see if the lock has since been relinquished]
c) Steal the lock
d) Report back some information about the nature of the lock so that
   the user might do something useful to resolve the blockage.

In a "wide open" system, all 4 options are potentially sensible.  In
a system where we wanted to be paranoid, some of the options might be
restricted to certain users or even outright forbidden.  [I don't like
that option much; there should be _someone_ that can clean up broken
locks...]
-- 
(concatenate 'string "cbbrowne" "@ntlug.org")
<http://www.hex.net/~cbbrowne/>
"I have yet  to see any problem, however  complicated, which, when you
looked at it in the right way, did not become still more complicated."
-- Poul Anderson