Roy Brown wrote:

> I meant that if you had a locking strategy that didn't recover too
> well when a conditional lock was refused, you might not notice this
> under normal circumstances, where locks weren't held for very long.
>
> But with unconditional locks queuing up, a record is effectively held
> locked, with no respite, for as long as it takes for all the requests
> to be serviced.

We have some of those "questionable strategy" locking schemes where we
lock around user input (timed user input in most cases) but we also use
item level locking, so there are rarely deadlocks.  These are
unconditional locks.

However, for adding/deleting masters, you need a set lock.  The set lock
will be queued if there are any item level locks held, and subsequent
item level locks queue up behind an unconditional set lock.  So in areas
like admissions where student masters are created, we do a conditional
lock; if it fails it prints "Waiting to add...", pauses 5 secs, repeat.
At least the session doesn't appear "dead".

Jeff Kell <[log in to unmask]>