Restarting automatic transactions

After an automatic transaction terminates, how an automatic transaction can restart depends on how it terminates. If the transaction terminates by deleting the transaction initiating procedure, only a client application can restart an automatic transaction by again remotely instantiating a transaction initiating procedure.

If a transaction initiating procedure is still active in the AppServer session, you can support the restarting of an automatic transaction using one of the following techniques, depending on how you code the transaction initiating procedure:

Automatic (chained) restarting — If you specify the CHAINED option for the TRANSACTION-MODE AUTOMATIC statement, a new automatic transaction starts immediately after the previous automatic transaction commits or rolls back. Thus, with the CHAINED option an automatic transaction is always open in the AppServer session until the transaction initiating procedure, itself, is made inactive (is deleted).

Manual restarting — If you do not specify the CHAINED option for the TRANSACTION-MODE AUTOMATIC statement, the client application can cause another automatic transaction to restart by calling any internal procedure of the active transaction initiating procedure. Thus, a remote call to an empty internal procedure can start a new automatic transaction.

Caution: In general, try to keep automatic transactions on an AppServer as short as possible. The multi-request feature of automatic transactions tend to encourage long transactions, and long transactions can make large or important segments of a database inaccessible to other ABL sessions for an indefinite period. This can create database deadlocks and traffic jams that can seriously retard the performance of multiple sessions. For more information on techniques to shorten automatic transactions, see the information on transaction management considerations in Design and Implementation Considerations.