A typical usage pattern-- correct me if there is a better way-- is to:
- start a transaction (NO LOCK TAKEN)
- do a series of selects to gather or verify state (SHARED)
- do a series of inserts/updates (with interspersed selects) to write new state (RESERVED)
... repeat selects/inserts/updates (RESERVED)
- end/commit transaction (UNLOCK)
It would appear that the lock level during a transaction can transition from SHARED to RESERVED, but will never fall from RESERVED back to SHARED until the transaction is completed, at which point in time the lock will fall back to UNLOCK.
If I have deduced the above correctly, then it would appear to be an advantage to be able to immediately push the lock to RESERVED upon entry into a transaction. If it is impossible to gain a RESERVED lock, then the initial selects are a waste of time and control can return immediately.
Obviously, I don't want such behavior to happen all the time. There are a lot of advantages to having SHARED locks during transactions until the point in time the RESERVED lock is really needed. I'm just looking for a way to mark the lock as RESERVED at the beginning of the transaction in certain special cases.
b.bum
