The WSO2 Message Broker (WSO2 MB) supports XA transactions (distributed transactions) from version 3.2.0 onwards. That is, WSO2 MB can now take the place of a resource manager and participate in a distributed transaction along with other resource managers (database servers, SAP R/3 system, etc.) that have the same support for distributed transactions.
The below diagram illustrates how WSO2 MB and two RDBMSs are set up as resource managers for a distributed transaction. In this example, a client (ESB profile of WSO2 EI) is sending an XA transaction. Each of the messages included in the XA transaction should be delivered to the relevant resource manager. However, if at least one of the resource managers fail to receive the message successfully, the XA transaction should be canceled.
Diagram: XA transaction sent to multiple resource managers.
In addition to the Resource Managers, the Application Program (AP) and the Transaction Manager(TM) are two other components that participate in the process of executing a distributed transaction. The AP and the TM components invoke different portions of the XA publisher implementation: The XAResource (calling the XA API) is handled by the TM, whereas that JMS session is handled by the AP.
Note that the TM and AP components are already embedded and set up in the ESB profile of WSO2 EI. Therefore, when you use the ESB profile as your JMS client, you do not have to implement these sections (relevant to the TM and AP) in the ESB's XA publisher (for example the proxy service).
However, if you are not using WSO2 EI's ESB to publish XA transactions to the broker, refer the sample XA publisher implementation given below. See how the TM and AM components are used in this implementation.
Read more about the XA specification in Java Transaction API (JTA) Specification 1.1.
Now, let's look at how distributed transactions work with a single broker node as the resource manager.For example, let's have the ESB profile of WSO2 EI as the client sending the distributed transaction. The messages belonging to this transaction should be delivered to three separate queues/topics in the Broker node. If at least one message fails, all the messages are rolled back.
Diagram: XA transaction distributed among queues in the broker.
Using WSO2 MB for XA transactions
Now, let's look at the various configurations that affect XA transactions when you work with WSO2 MB.
See the following topics for details:
MVCC-enabled database for the MB store
WSO2 MB requires a separate database for storing MB-specific data. When you use XA transactions, be sure that MVCC is enabled for the database you use.
See Changing the Default MB Database for instructions.
Configuring the maximum number of XA transactions
You can configure the maximum number of distributed transactions that can be handled in parallel by WSO2 MB. To do this, set the following parameter in the
broker.xml file (stored in the
Failover of XA transactions
As explained above, the behavior of XA transactions is straightforward when you use a single broker node. However, if you have a clustered setup, you need to correctly configure the failover method for you XA transactions.
Let's consider a scenario where the client (for example, the ESB profile) is sending messages to a cluster of broker nodes. In a typical multi-node cluster, when one node fails to connect with the client, the client should be able to connect to the next available node (i.e., failover to the next available node) and continue the transactions. This behavior of failing over to the next available node should be configured using the failover method for the connection.
However, XA transactions sent to the broker cluster should not be allowed to failover from one node to another before all the messages (belonging to that transacted connection) are successfully committed to one node. Therefore, in the event that the connection between the client (sending the XA transaction) and the broker node breaks before all the messages are successfully committed to that node, all the messages should be rolled back. That is, the XA transaction should be canceled. The client can then reconnect to the next available broker node in the cluster and resend all the XA transactions to that broker node. The onetime failover method supports this requirement for XA transactions.
Test distributed transactions with WSO2 MB
You can see how this works by following the steps given below.
- Follow the instructions in configuring the ESB profile with WSO2 MB.
- Start WSO2 MB and create three queues: mbqueue1, mbqueue2, and mbqueue3
Start the ESB profile and add a proxy service to mediate messages to the broker. To handle XA transactions, the proxy service should be configured as shown below. In this example, the ESB listens to a JMS queue named MyJMSQueue and consumes messages and sends messages to multiple JMS queues in a transactional manner.Sample Proxy Service
Now, you can disable one queue in the broker and send a message to the ESB profile. The proxy service will attempt to dispatch the message to all three queues. However, since one queue is unavailable, the message will not be delivered to any of the queues.