A transacted session allows an application to send or receive groups of messages as one atomic operation:

  • A session that is transacted for sending guarantees that either all messages in a group are sent, or none is sent
  • A session that is transacted for receiving guarantees that a group of received messages are acknowledged only after all messages in the group are successfully processed

The following table lists the methods available for controlling the execution and recovery of transactions.

Table 1. Managing transaction attributes
Setting Rolling back
commitSend procedure commitReceive procedure rollbackSend procedure rollbackReceive procedure

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 setTransactedSend procedure, the setTransactedReceive procedure, 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.

Transacted sending

When an application calls the commitSend procedure in a Session object, all messages that have been published or sent to a queue with the current transaction are sent. When an application calls the rollbackSend procedure in a Session object, all such messages are discarded.

Transacted receiving

When an application calls the commitReceive procedure in a Session object, all messages that have been received with the current transaction are acknowledged. When an application calls the rollbackReceive procedure in a Session object, all such messages are re-received (yielding the same effect as calling the recover procedure in a nontransacted session).

Illegal calls: recover and setNoAcknowledge

Since message acknowledgement and recovery are handled automatically in a transacted session, it is an error to call the recover procedure and setNoAcknowledge procedure in a session that is transacted for receiving.

ABL transactions and JMS transacted sessions

ABL transactions and JMS transactions are not integrated. For example, a DO TRANSACTION block might be rolled back while the JMS calls inside the transaction block are committed. The OpenEdge application must synchronize between ABL transactions and JMS transactions.

Note: For information about the handling of errors and error conditions, see Error and condition handling .