Record-level transactions, Exceptions – HP Integrity NonStop J-Series User Manual
Page 60
Configuring Automatic Transaction Processing
HP NonStop AutoTMF Software User’s Guide—429952-017
4-12
Record-Level Transactions
Record-Level Transactions
Certain programs use a complex record-locking and record-unlocking sequence such
that at least one record is locked for long periods. AutoTMF will not commit an
automatic transaction until a program releases all locks obtained under the transaction.
If the processing contains no point where all locks are released, the automatic
transaction is never committed.
The resulting long-running transaction can cause lock contention, deadlocks, and,
eventually, a unilateral abort when the TMF AutoAbort time limit is reached.
Uncommitted updates could be lost. See the discussion in
In such cases, you can configure AutoTMF to generate one automatic transaction for
each record lock and to commit each transaction as soon as the record is unlocked.
This approach increases the transactional activity but prevents the occurrence of long-
running transactions without changing the program’s locking behavior.
This feature is enabled by specifying the RECORDTX attribute on both the file on
which the locks are held and the accessing program. If RECORDTX is specified on
either the file or the program, but not on both, RECORDTX is ignored.
To implement RECORDTX, AutoTMF maintains a table of records locked and the
associated transaction for each lock. If the same record is locked multiple times, the
same transaction is used for each lock until the lock is released and the transaction is
committed.
Exceptions
Certain sequences of operations do not lend themselves to the generation of automatic
transactions for each record lock. In these cases, the RECORDTX attribute is not
supported and cannot be used:
If a program issues READLOCK (In COBOL, READ NEXT WITH LOCK) to read
records sequentially, AutoTMF cannot predict the key of the next record that will be
locked, so AutoTMF cannot identify which transaction to use if the same record is
locked more than once. As long as READLOCK is used to lock records that are not
already locked, READLOCK may be used with RECORDTX.
If a program does a LOCKFILE after locking two or more records, the file cannot
be locked unless the records are unlocked first. Otherwise, the same record could
be locked under more than one transaction, leading to internal deadlocks. If a
LOCKFILE operation that has more than one record lock is requested, the
LOCKFILE operation will be abended.
If a program issues READUPDATELOCK with positioning by a unique alternate
key, AutoTMF cannot predict the primary key of the record being locked, so
AutoTMF cannot identify which transaction to use if the same record is locked
more than once. As long as READUPDATELOCK is used to lock records that are
not already locked, READUPDATELOCK may be used with RECORDTX.