Distributed Transaction Support

Distributed Transaction Support involves handling two or more transactions, often using multiple databases, in a coordinated way. A transaction manager is setup in the middle of these transactions for effective coordination and management.

The 'Data Service Hosting' feature uses Java Transaction API (JTA), which allows distributed transactions to be carried out across multiple XA resources in a Java environment. Overriding this transaction manager by your own is also facilitated by this feature.

Distributed Transaction facility is disabled in a data service by default. Follow the instructions to enable it.

1. Log on to the product's management console and select "Data Service -> Create" under the "Main" menu.

2. The "Create Data Service" page appears. The Data Service name is mandatory. Tick the "Enable Distributed Transactions" check box. For example,

3. Click Next to enter the data source details for the data service.

In this example, we use data source type as RDBMS and XA-DataSource from the drop-down menu as follows:

After the XA-DataSource is created,  it can be used as a usual data source in queries. You can simply use the boxcarring facility to create and execute a distributed transaction. When boxcarring takes place, it automatically detects that we are dealing with a XA-DataSource.  Also, since distributed transactions are enabled in the service, the necessary steps will be executed to run this in JTA mode.

Reliable Messaging with Distributed Transactions

Let's look at reliable messaging with JMS. JMS has ability to participate in distributed transactions. Therefore, we can use JMS as the communication channel and our database transactions can be run in a single, distributed transaction. This guaranteed no message loss or failures and ensures single, successful message delivery.

To enable this featue in a data service, you only have to enable the distributed transactions option as discussed above. The data service automatically senses the status when an incoming message arrives and if a JTA transaction is already started, it automatically binds to that. In this scenario, the aforementioned starting of the transaction is done using the JMS transport receiver. Therefore, you have to enable the JMS transport receiver mentioned in <PRODUCT_HOME>/repository/conf/axis2.xml. Also add the following two properties to configure the transport receiver to use JTA transactions.

• jta
• true

The axis2.xml file contains properties related to Apache ActiveMQ JMS broker by default. Change the settings as suitable to the JMS broker you are using. Also, the required dependent libraries should be added to <PRODUCT_HOME>/repository/components/lib.

After the JMS transport is configured, you can use any JMS client to send messages to the configured JMS broker. This can also be done using the Try-it tool offered by Data Services Server. In order to do this, the client axis2.xml file, which is located at <PRODUCT_HOME>/repository/conf/axis2_client.xml should be edited. The code block for JMSSender has to be commented out to enable the JMS transport sender.

An example execution of a data service which uses distributed transactions with JMS is shown below:

Overriding the Default Transaction Manager

The default transaction manager of a server can be overridden by providing the location to a JNDI name that the transaction manager is bound to. This is specially useful when the server is embedded in other application servers where they are not using the standard JNDI name to bind to the transaction manager. In this case, a custom JNDI name can be provided in order to detect the transaction manager.

Shown below is an example how a data service has overridden the default transaction manager by WebLogic's JTA transaction manager.

You can find a demo of how distributed transaction support works in the Data Services Server in section, Distributed Transactions Sample of the WSO2 Data Services Server 2.6.3 Documentation.