HP Integrity NonStop H-Series - Manual (Page 62)

Configuring Automatic Transaction Processing
HP NonStop AutoTMF Software User’s Guide—429952-013
4-18
Forced Transaction Commit
Reducing causes of unilateral aborts
To reduce other causes of unilateral aborts in production processing, perform these
tasks:
•
Configure TMF to handle the projected transaction load.
•
If programs hold record locks and file locks for long periods, alter the TMF
AutoAbort parameter to avoid aborting long-running automatic transactions. If TMF
version 3.6 or later is running in your system, another option is to configure a
timeout for automatic transactions. See
Setting Transaction Time Out below.
•
Avoid using the TACL STOP and the PATHWAY SHUTDOWN2 MODE
IMMEDIATE commands unless you know that the programs being stopped do not
have pending transactions. Use the
STOP PROCESS command to externally stop
server processes that are reading $RECEIVE
Forced Transaction Commit
As mentioned in the paragraph on Transaction Commit , NonStop AutoTMF software
ensures that normal unaudited locking protocols are observed in order to preserve the
integrity of the program logic. NonStop AutoTMF software assumes that programs are
locking and unlocking records as needed to process a business transaction or unit of
work. Automatic transactions are therefore not committed if a program is holding a lock
on a record or a file.
The case where a program does not conform to the unaudited locking protocol
presents a problem. If a program fails to unlock a record or a file, the program prevents
NonStop AutoTMF software from committing automatic transactions. To deal with such
situations, AutoTMF issues a warning in the EMS log to notify the operator of the long
running transaction when a transaction runs longer than 5 minutes. The warning is
repeated every 5 minutes, until the transaction is committed. (You can suppress these
warnings by setting the file or program attributes
NOWARNLONGTX or the global
parameter ATMFNOWARNLONGTX)
Eventually, a long running transaction can reach the TMF AutoAbort limit, at which
point the transaction is unilaterally aborted and uncommitted updates are rolled back,
causing potentially irrecoverable data loss.
While forcing a commit before a program has released locks is tantamount to altering
the program’s logic and would leave the program in an uncertain state, failing to
commit the transactions before reaching the unilateral abort is not an option.
To prevent the loss of data in cases where the program’s behavior causes a unilateral
abort, AutoTMF uses a configurable AUTOCOMMIT timer. The AutoTMF runtime
monitors automatic transactions to determine if any have been active for more than the
AUTOCOMMIT time limit.
The process must be active, either receiving messages on $RECEIVE or performing
database positioning operations. Processes in a "wait" state are not monitored for long
transactions.