+

Search Tips   |   Advanced Search

 

Message-driven beans - transaction support

 

Message-driven beans can handle messages on destinations (or endpoints) within the scope of a transaction.

 

Transaction handling when using the Message Listener Service with WebSphere MQ JMS

There are three possible cases, based on the MDB deployment descriptor setting you choose: container-managed transaction (required), container-managed transaction (not supported), and bean-managed transaction. For related information see Message-driven bean deployment descriptor properties.

Container-managed transaction (required)

In this situation, the appserver starts a global transaction before it reads any incoming message from the destination, and before the onMessage() method of the MDB is invoked by the appserver. This means that other EJBs that are invoked in turn by the message, and interactions with resources such as databases can all be scoped inside this single global transaction, within which the incoming message was obtained.

If this application flow completes successfully, the global transaction is committed. If the flow does not complete successfully, (if the transaction is marked for rollback or if a runtime exception occurs), the transaction is rolled back, and the incoming message is rolled back onto the MDB destination.

Container-managed transaction (not supported)

In this situation there is obviously no global transaction, however the JMS provider can still deliver a message from an MDB destination to the appserver in a unit of work. You can consider this as a local transaction, because it does not involve other resources in its transactional scope.

The appserver acknowledges message delivery on successful completion of the onMessage() dispatch of the MDB (using the acknowledgement mode specified by the assembler of the MDB).

However, the appserver does not perform an acknowledge, if an unchecked runtime exception is thrown from the onMessage() method. So, does the message roll back onto the MDB destination (or is it acknowledged and deleted)?

The answer depends on whether or not a syncpoint is used by the WebSphere MQ JMS provider and can vary depending on the operating platform (in particular the z/OS operating platform can impart different behavior here).

If WebSphere MQ establishes a syncpoint around the MDB message consumption in this container-managed transaction (not supported) case, the message is rolled back onto the destination after an unchecked exception.

If a syncpoint is not used, then the message is deleted from the destination after an unchecked exception.

For related information, see the technote 'MDB behavior is different on z/OS than on distributed when getting nonpersistent messages within syncpoint'http://www-1.ibm.com/support/docview.wss?rs=171&context;=SSFKSJ&context;=SSWHKB&q1;=syncpointAllGets&uid;=swg21231549&loc;=en_US&cs;=utf-8⟨=en

Bean-managed transaction

This situation is similar to the container-managed transaction (not supported) case. Even though there might be a user transaction in this case, any user transaction started within the onMessage dispatch of the MDB does not include consumption of the message from the message-driven bean destination within the transaction scope. To do this, use the container-managed transaction (required) scenario.

 

Message redelivery

In each of the previous three cases, a message that is rolled back onto the MDB destination is eventually re-dispatched. If the original rollback was due to a temporary system problem, you would expect the re-dispatch of the MDB with this message to succeed on re-dispatch. If, however, the rollback was due to a specific message-related problem, the message would repeatedly be rolled back and re-dispatched. This would be an inefficient use of processing resources. The appserver handles this scenario which is known as a poison message scenario, by tracking the frequency with which a message is dispatched, and by stopping the associated listener port after a specified number of redeliveries has occurred. This is a configurable value on the Maximum Retries property on a listener port. For more information, see Listener port settings.

A Maximum Retries value of zero stops the listener port after a single failure to successfully complete an onMessage(). Because stopping the listener port stops the processing for all MDBs mapped to that listener port, this solution is rather unspecific. Instead of relying on the WebSphere Application Server message listener service to stop the listener port if a poison message scenario occurs, the other solution is to set up a backout queue (BOQUEUE), and a backout threshold value (BOTHRESH). If you do this, WebSphere MQ handles the poison message. For more information on handling poison messages, see the WebSphere MQ Using Java book

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US&FNC;=SRX&PBL;=SC34659101

 

Inbound resource adapter transaction handling

An MDB can be configured for bean or container transaction handling. The owner of the resource adapter owner must tell the MDB developer how to set up the MDB for transaction handling.


 

Related concepts


Message-driven beans - automatic message retrieval