> Surely there must be a solution other than not having entries locked during
> "think" time?
 
If you mean that you hold locks across terminal reads, there are alternatives
to this.  Lock contention is rarely a problem for short transactions.
 
You can use a field in the record to mark it for a "soft lock."  This is like
a "read with intent to write" lock, but you have to do it yourself.  You
have to make sure that you unlock the record whether you modify it or not.
The difficult case is when your program aborts!  There are ways to deal with
this.
 
For example,
  Lock record
  see if "soft lock is set"
    if not,
      put your PIN and the time in the soft lock field
    if there is a soft lock
      check to see if the process that set the soft lock is still alive
         (Note that PINs may be reused so extra work may be required)
      if not,
        replace its soft lock with your own
      else
        sorry charlie (tell user that someone else is modifying data)
 
  if your softlock was successful
    update record
 
  unlock record
 
  Let user do what he wants
 
  lock record
  write new data but zero out soft locks
  unlock record
 
This is one approach.
 
Ken Hirsch
Carrboro, N. C.
 
Note for everybody:
  Disk is "free" (~ $500/gigabyte)!
  If your users can use day-old data for reporting,
  make sure you keep an extra copy of your database around.