AutoTMF Software User's Guide (Update 11)

Configuring Automatic Transaction Processing
HP NonStop AutoTMF Software User’s Guide—429952-013
4-12
Suppressing Inherited Transactions
•
FETRANSABRTTIMEOUT (96)
•
FEABORTEDTRANSID (97)
•
FENOMORETCBS (98)
Suppressing Inherited Transactions
A non TMF-aware server may inherit a transaction from a TMF-aware requester when
reading $RECEIVE. The transaction has no effect on the program. However, if
NonStop AutoTMF software is configured, the inherited transaction becomes visible to
the program.
When NonStop AutoTMF software detects an inherited transaction, NonStop AutoTMF
software assumes that the process will use that transaction to access audited files.
Suppressing inherited transactions insures that NonStop AutoTMF software generates
automatic transactions for all audited file accesses, emulating the behavior of a non
TMF-aware process.
UNLOCKFILE Optimization
Non TMF-aware programs sometimes issue a blanket call to UNLOCKFILE to release
all locks rather than managing locks individually. In high-volume environments, the cost
of UNLOCKFILE can be noticeable. When files are audited, the transaction commit
unlocks records that participate in the transaction, making the UNLOCKFILE
redundant.
NonStop AutoTMF software can be configured to eliminate the call to UNLOCKFILE.
Since the program has released all locks on the file by issuing the UNLOCKFILE,
NonStop AutoTMF software attempts to commit the transaction, following the usual
rules for committing an automatic transaction. If a lock is held on another file
participating in the transaction, the commit will occur when this lock is released by the
program.
Note that this optimization can only be enabled for files that are also enabled for
automatic 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. NonStop AutoTMF software 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 Unilateral Aborts discussion below.