The following table lists the methods available for controlling the execution and recovery of transactions.
The typical Java–JMS transacted application uses two sessions, one for transacted sending and one for transacted receiving. The ABL–JMS implementation uses two JMS sessions behind the scenes, but at the ABL API level, there is only one Session object.
The application controls whether sending, receiving, or both are transacted. It makes the session transacted by calling the
setTransactedSendprocedure, the
setTransactedReceiveprocedure, or both in the Session object.
A session that is transacted for sending, receiving, or both is constantly in a transaction mode. When a transaction is committed or rolled back, a new one is automatically started.