Message-driven beans - transaction support
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)
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. We 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.
- 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.
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. For poison message scenarios, set up...
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