Message-driven beans - transaction handling with service integration bus
Message-driven beans can handle messages on destinations (or endpoints) within the scope of a transaction.
There are three possible cases, based on the message-driven bean deployment descriptor setting you choose: container-managed transaction (required), container-managed transaction (not supported), and bean-managed transaction.
In the message-driven bean deployment descriptor settings, you can choose whether the message-driven bean manages its own transactions (bean-managed transaction), or whether a container manages transactions on behalf of the message-driven bean (container-managed transaction). For information about the message-driven bean deployment descriptor settings, see Message-driven bean deployment descriptor attributes. If you choose container-managed transactions, in the deployment descriptor notebook, you can select a container transaction type for each method of the bean to determine whether container transactions are required or not supported. The default container transaction type is required.
- Container-managed transaction (required)
In this case, the application server starts a global transaction before it reads any incoming message from the destination, and before the
onMessage()method of the message-driven bean is invoked by the application server. 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 message-driven bean destination.
- Container-managed transaction (not supported)
In this case there is no global transaction, but the JMS provider can still deliver a message from a message-driven bean destination to the application server 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 application server acknowledges message delivery on successful completion of the
onMessage()dispatch of the message-driven bean (using the acknowledgement mode specified by the assembler of the message-driven bean).However, the application server does not perform an acknowledge, if an unchecked runtime exception is thrown from the
onMessage()method. So, does the message roll back onto the message-driven bean destination (or is it acknowledged and deleted)?The answer depends on whether a syncpoint is used by your JMS provider and can vary depending on the operating platform (in particular the z/OS® operating platform can impart different behavior here).
If your JMS provider establishes a syncpoint around the message-driven bean 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
In this case, the action 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 message-driven bean 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.