Progress
External Program
Interfaces
Transacted Sessions
A transacted session allows an application to send or receive groups of messages as one atomic operation:
The application controls whether sending is transacted, message receiving is transacted, or both. The typical Java–JMS transacted application uses two sessions, one for transacted sending and one for transacted receiving. The 4GL–JMS implementation uses two JMS sessions behind the scenes, but at the 4GL API level, there is only one Session object.
An application can call the setTransactedSend, the setTransactedReceive procedure, or both, in the Session object to make the session transacted. An application calls both procedures to make a session transacted for sending and receiving.
A transacted session (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 commitSend in a Session object, all messages that were published (or sent to queue) up to that point with the current transaction, are sent. When an application calls rollbackSend in a Session object, all messages that were published up to that point (or sent to queue) with the current transaction, are discarded.
Transacted Receiving
When an application calls commitReceive in a Session object, all messages that were received up to that point with the current transaction are acknowledged. When an application calls rollbackReceive in a Session object, all messages that were received up to that point with the current transaction are re-received (the same effect as calling recover with a nontransacted session).
No Recover and setNoAcknowledge Calls
Since message acknowledgment and recovery are handled automatically in a transacted session, it is an error to call the recover and setNoAcknowledge methods in a session that is transacted for receiving.
4GL Transactions and JMS Transacted Sessions
4GL 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 4GL application must synchronize between 4GL transactions and JMS transactions.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |