In addition to the transaction mediator, WSO2 ESB also supports JMS transactions. The JMS transport shipped with WSO2 ESB supports both local and distributed JMS transactions. You can use local transactions to group messages received in a JMS queue. Local transactions are not supported for messages sent to a JMS queue.
A local transaction represents a unit of work on a single connection to a data source managed by a resource manager. In JMS, we can use the JMS API to get a transacted session and call methods for commit or rollback for the relevant transaction objects. This is managed internal to a resource manager. There is no external transaction manager involved in the coordination of such transactions.
To start a local JMS transaction, define the following property in JMS Transport Listner/Sender in
By default the session is not transacted and if you want to use JMS local transaction set the above parameter to
true. And you need to set the following property in Synpase fault handler to rollback the transaction in case of a failure.
If you are using a JMS Inbound endpoint for the transaction, set the scope of the
SET_ROLLBACK_ONLY property to
default as follows:
<property name="SET_ROLLBACK_ONLY" scope="default" type="STRING" value="true"/>
The WSO2 ESB also has the support for distributed JMS transaction. You can use JMS Transport with more than one distributed resources( for example a JMS queue and a remote database server).
The Transaction Mediator can be used to mark a distributed transaction which involves a distribution transaction which span through multiple JMS resources.
In the following scenario, a message will be read from a JMS queue and it will be processed by a back end service. While executing one sequence, ESB will receive a fault and this will cause the JMS transaction to rollback. In the successful scenario, the transaction will be committed and the request will be sent to the back end service. In the following configuration, there is a Class Mediator which will set a property called
MESSAGE_COUNT to the message context and it will demonstrate this behavior. Depending on the value of this variable the decision to either commit or rollback the transaction will be taken. You can download the binary ZIP of the mediator from here. Drop this mediator to
The source of the mediator looks as shown below.
ESB configuration is given below.
To start a local JMS transaction, define the following property in JMS transport Listner in
By default, the session is not transacted and if you want to use JMS local transaction, set the above parameter to true. Also note the following property in the failure case which will roll back the local transaction.
You do not need to deploy the ESB on JBOSS to run this sample since this does not require any distributed transaction manager as in other cases.
1. Copy the JMS client JARs (activemq-core-5.2.0.jar, geronimo-j2ee-management_1.0_spec-1.0.jar, geronimo-jms_1.1_spec-1.1.1.jar) into
the following location:
2. Start the activemq server.
3. Deploy and start the
SimpleStockQuoteService service. Get the
SimpleStockQuoteService service attach with this article (SimpleStockQuoteService.aar) and place it in
4. Start WSO2 ESB with above configuration.
5. Run the JMS client with following command:
When you run the client, you can see two log lines saying that first time the traction was rolled back and in the second attempt the transaction was committed. And service will be served to the message received.
WSO2 ESB has the support for distributed JMS transaction. In this case, you can use the Transaction Mediator to manage multiple distributed resources. An ideal candidate for this category would be handling a JMS queue and a data base server using a single transaction. A sample configuration will be very similar to the distributed transaction example configuration given in the section on distributed transactions.