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.
- For a receiver bean (deployed as a message-driven bean), incoming message
receipts are defined by the Transaction attribute of the onMessage() bean
method. Message-driven beans can use bean-managed transactions (BMT) or container-managed
transactions (CMT). For message-driven beans using CMT there are only two
supported transaction options: Not supported and Required.
If a message is to be received within a transaction, the message-driven bean
must be using CMT with the Transaction attribute set to Required.
- For a receiver bean as a session bean, the bean only supports container-managed
transactions, and the behaviour is defined by the Transaction attribute of
the receiver bean method.
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:
- Receiver bean.
To limit the number of times that
a transaction is retried, you can either rely on the facilities of the JMS
provider or use the retry limit facility of the Message Listener:
- WebSphere MQ JMS support provides the ability to move the message to a
backout queue and uses two queue attributes, the backout threshold and the
backout-requeue queue, to perform this.
- The Message Listener retry count can be used to stop the listener processing
the queue if the threshold is reached. The listener behaviour can be disabled
by setting the retry count value higher than the JMS provider threshold value.
- Application-callable receiver bean.
To limit the number of times
that a transaction is retried depends on the facilities of the JMS provider
to move the message to a backout queue.
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.

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