I would suggest a dummy update or insert just after the BEGIN TRANSACTION that does not do anything meaningful, just creates the RESERVED lock.
On Sat, 2004-09-25 at 00:30, b.bum wrote: > Is there a way to do a 'begin transaction' directly at the RESERVED > locking level? > > 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 -- Edward A. Macnaghten http://www.edlsystems.com
