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.
...
Diagram: XA transaction sent to multiple resource managers.
Info | |||||||
---|---|---|---|---|---|---|---|
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 inJava 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.
...