>  > Provide concurrent TurboIMAGE read-only DBLOCK mode
> > (guaranteed repeatable read): Allow multiple readers, but force
> > all DBLOCKs for WRITE access to be treated serially while
> > READ lock is in effect.
> 
> Good thing Steve restated the request.   The last sentence in the
> "official" version seems to get the idea exactly backwards.   You
> shouldn't be able to update while *any* lock is in place.

Maybe just the difference between a windba...er, expanded statement vs.
the "sound byte" style of the "official" version.

> But I'm still confused.   How are multiple read locks resolved when
> one of the holders of the locks wants to upgrade his lock to a
> read/write lock?   For instance:
> User A has a read only lock on record #100.   So does user B.    Now
> user A wants to upgrade his lock to a read/write lock.   So does user
> B.   Seems like we have a deadlock condition.   Seems like either I'm
> not making the right assumptions and/or the enhancement idea is
> incomplete.

No, you're right about the deadlock potential, and that's exactly why I
put in the proviso that a process holding a read lock can only ask for a
lock upgrade if it is the only lock holder. Well, it can ask any time,
but, if there are any other locks in place on the items to be upgraded,
it will get back an appropriate error code. The existing 2x error codes
should work for a conditional upgrade request, but we may want a new
error code for an unconditional upgrade request when there are other
read locks on the item. Something that says "not only can I not give you
the requested lock right now, but I can't safely accept your
unconditional lock request into the queue; try later." Or not; we could
just use 26 for that situation, since potential deadlock is the reason
the lock request can't be accepted. Or, HP could make the system smart
enough to accept the first unconditional upgrade request, and fail the
second one with error 26, since the second request sets up a bona fide
"imminent deadlock" condition. Lots of possibilities.