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 client.
This section covers:
JMS Local Transaction
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.
Let's demonstrate, through a sample scenario, how to handle Transaction using JMS in a situation where the back-end service is unreachable.
The sample scenario is as follows:
- A message will be read from a JMS queue and it will be processed by a back-end service.
- Failure scenarios: While executing one sequence, if a failure occurs, ESB will receive a fault and this will cause the JMS transaction to rollback.
- Successful scenario: The transaction will be committed and the request will be sent to the back-end service.
The scenario is depicted in the diagram below.
Let's see how to build and invoke this sample scenario in the ESB. Before proceeding, refer to the Prerequisites section in ESB Samples Setup.
Building the Sample Scenario
1. First, configure the JMS local transaction.To start a local JMS transaction, define the following property in JMS Transport Listener in <ESB HOME>/repository/conf/axis2/axis2.xml. By default the session is not transacted. In order to make it transacted, set the following parameter to true.
Once done, the axis.xml file should look as follows,
2) Set the synapse configuration. For example, in the following configuration, the message will be taken from the JMS queue and send to SimpleStockQuoteService running on the Axis2 back-end server. If it fails to achieve the task, the message will be rolledback.
The source of the ESB Configuration is as follows:
In case of handle failure, the property SET_ROLLBACK_ONLY has to be set to true in Synapse fault handler to rollback the transaction.For example,
3. Deploy the back-end service SimpleStockQuoteService and start the Axis2 server using the instructions given in section Starting Sample Back-End Servicese.
You now have a running ESB instance, ActiveMQ and a sample back-end service to simulate the sample scenario. Next, proceed to client JMS execution.
Because of the asynchronous behavior of the Send Mediator, you cannot you use it with an http/https endpoint, but you can use it in asynchronous use cases (such as with another JMS as endpoint).
Executing the Sample Scenario
We have described below both the successful and failure scenarios.
4. Run the sample JMS Client by executing following ant command from <ESB_HOME>/samples/axis2Client directory. This will trigger a sample message to the JMS Server.
If the message is mediated successfully, it should display an output on the Axis2 server's start-up console. For example,
5. Note, on the ESB's debug log, a message of type INFO that indicates that the transaction is committed. For example,
6. In order to simulate the failure scenario, stop the sample Axis2 Server and run the same code snippet given for JMS client in step 4 above.
7. Note that WSO2 ESB log shows a message as follows:
JMS Distributed Transaction
The WSO2 ESB also has support for distributed JMS transactions. You can use JMS Transport with more than one distributed resources (for example, a JMS queue and a remote database server). An external transaction manager coordinates the transaction. Designing and using JMS distributed transactions is more complex than using local JMS transactions.
The Transaction Mediator can be used to mark a distributed transaction, which involves a distribution transaction that spans through multiple JMS resources. The transaction manager is the primary component of the distributed transaction support infrastructure. However, the JDBC driver (the resource adapter) and the application server (in which you deploy the applications) should have the following two characteristics:
- The driver should implement the JDBC 2.0 API (including the optional package interfaces XADataSource and XAConnection) or higher, and the JTA interface XAResource.
- The application server should provide a Datasource class that is implemented to interact with the distributed transaction infrastructure and a connection pooling model for performance improvements.
When JMS transactions are in place, local transactions are managed by the JMS provider itself whereas the distributed JMS transactions are managed by the XAResource enabled transaction manager in the Java EE application server.
Check if your application server provides a XAConnectionFactory when you look for the ConnectionFactory.