TurboIMAGE/XL Database Management System Reference Manual MPE/iX V6.5 (30391-90011)

Chapter 7 317
Logging and Recovery
Logical Transactions
Locking Examples
Examples of the two recommended locking schemes follow:
Single Lock Strategy
DBLOCK for account 2,18,34 Lock should precede DBBEGIN call.
DBBEGIN
DBGET data for account 2
DBPUT data for account 34
DBGET data for account 18
DBDELETE data for account 18
DBEND
DBUNLOCK for all accounts DBUNLOCK must be last call.
Multiple Lock Strategy
DBLOCK account 2,34
DBBEGIN
DBGET data for account 2
DBUPDATE data for account 2
DBPUT data for account 34
DBLOCK for account 18
DBGET data account 18
DBDELETE data account 18
DBEND
DBUNLOCK for all accounts DBUNLOCK must be last call.
CAUTION Use caution when employing a multiple lock strategy requiring Multiple RIN
(Resource Identification Number) capability, also known as MR capability;
refer to appendix D for information. Hewlett-Packard does not accept
responsibility for possible deadlocks or system lockouts that could result from
improper use of the MR capability.
In the first example above, calling DBLOCK before DBBEGIN makes the transaction shorter in
duration. The recommendation is to call DBLOCK first, because there is no way of knowing
how long DBLOCK will have to wait to acquire the lock after the transaction has begun. For
additional locking information, refer to "Using the Locking Facility" in chapter 4.
Locking and Dynamic Transactions
Because dynamic transactions can be rolled back by calling DBXUNDO and are automatically
rolled back in case of a system failure or program abort, TurboIMAGE/XL requires that a
dynamic transaction be independent of all other transactions. When the database is
opened in access mode 3 or 4, transaction independence is guaranteed because the
program is the only modifier of the database.
When the database is opened in access mode 1, dynamic transactions require the
programmer to use strong locking. A call to DBUNLOCK must occur after the call to DBXEND.
Failure to follow this sequence after a call to DBPUT, DBDELETE,orDBUPDATE will cause an
error. Intrinsic calls within the dynamic transaction must have covering locks. If an error