[Enterprise Extensions only]

Extended messaging, transaction support

The extended messaging service can handle messages read from JMS destinations within the scope of a transaction. If transaction handling is specified for a JMS destination, the JMS Listener starts a global transaction before it reads any incoming JMS message from that destination. When the message bean processing has finished, the JMS Listener commits or rolls back (using JTA transaction control) the transaction.

To configure WebSphere to provide transactional support for the extended messaging service, you complete the following stages:

  1. Use the JMSAdmin tool to configure the WAS name space to specify that you are using WebSphere JMS/XA connection factories.
    Note: To enable support for global transactions, you must use the WebSphere JMS/XA connection factories, because these ensure proper transaction behavior.
  2. Edit the extended messaging configuration file to specify the transactional requirements separately for each JMS destination.
  3. Use the application assembly tool to configure the onMessage() method of the message bean to support the transactional behavior that you want. For future compatibility with the EJB2.0 specification, message beans specify either bean-managed transactions (BMT) or container-managed transactions (CMT) with a transaction behavior of TX_NOT_SUPPORTED or TX_REQUIRED.

Notes:

  1. All messages retrieved from a specific destination have the same transactional behavior.
  2. To enable the transactional behavior that you want, you must specify the same transaction behavior in the extended messaging configuration file as you configure for the onMessage() method of the message bean.
  3. If a destination does not need global transaction support, you can configure the WAS name space using standard non-XA JMSConnectionFactories.
  4. If you use non-WebSphere XA connection factories, JMS resources are not recovered if the server fails.

If messages are queued to be sent within a global transaction they are sent when the transaction is committed. If the processing of a message causes the transaction to be rolled back, then the message that caused the bean instance to be invoked is left on the JMS destination.

You can use the MaxRetries configuration option for the destination to define the maximum number of times the JMS Listener attempts to read a message from the destination. When MaxRetries has been reached, the JMSListener for that destination is stopped. When you have resolved the problem, you must then stop and restart the given message bean's EJB module from Systems Management.