Extended messaging - transactional support

The global transaction context is not flowed on asynchronous (messaging) requests, so the receipt of an asynchronous message cannot be part of some existing remotely-established transaction. Reliability in an asynchronous environment is built on the message provider's ability to guarantee a once-and-once-only message delivery.

Transactional support with extended messaging builds on, and extends, the transactional support provided with bean-managed messaging, as follows:

Transactional support for receiving messages (receiver beans)

The extended messaging transactional behaviour for receiver beans depends upon whether the bean is a receiver bean or an application-callable receiver bean.

Dealing with retries: In the asynchronous environment of transaction processing, rolling back a message receipt means that the message is not removed from the source destination. Although this behaviour is desirable and correct, it causes the message retained on the source queue to be reprocessed until the transaction commits. For receiver beans, you can control this behaviour as follows:

Transactional support for sending messages (sender beans)

The transactional behaviour for sending messages is defined by the Transaction attribute on the send method within the sender bean.

If the send() method is part of a transaction, then the sending of an outgoing message occurs within any currently active transaction. This means that the message is not transmitted until the transaction is committed. If no transaction is active when the request to send the message occurs, then the message is transmitted immediately.

The transactional behaviour where the mode of interaction for a sender bean method specifies a response (that is, either Send message and receive synchronous response or Send message and receive deferred response) depends upon the type of response, as follows:

Transactional behaviour for a synchronous response
The sending of the request message and the receipt of the response message cannot be performed inside a transaction, because they are both performed within the same method. Therefore, the send is always non-transactional, regardless of the transactional setting for the method. The receive is either transactional or not, depending upon the Transaction setting of the method.
Transactional behaviour for a deferred response
The response message is received by a receiveResponse() method, which can have a different transactional behaviour to the sender method inside the sender bean. The transaction containing the send command must commit before the response can be received. The transactional behaviour is specified on the send and receive methods of the Sender bean.


Related concepts
Extended messaging - receiving messages
Extended messaging - sending messages
Extended messaging - data mapping
Extended messaging - handling late responses
Extended messaging - application usage scenarios



Searchable topic ID:   cmc_ovw07
Last updated: Jun 21, 2007 8:07:48 PM CDT    WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/cmm/concepts/cmc_ovw07.html

Library | Support | Terms of Use | Feedback