XA and Non XA Transactions in SOA

There are two types of Transactions. 

- Non-XA - Local Transactions

- XA-Transactions

1) NON-XA Transaction - Non XA Transaction is a local transaction. It commits the transaction irrespective of the other adapters in the same business flow. Weblogic have provided an additional option to enable a support for global transactions for Non XA datasources too. This helps the local transaction resource manage to participate in global transaction. It uses the transaction manager of the global transaction resource as it doesnt have one of its own. It has three transaction options.

·         Logging Last Resource: With this option, the transaction branch in which the connection is used is processed as the last resource in the transaction and is processed as a local transaction. Commit records for two-phase commit (2PC) transactions are inserted in a table on the resource itself, and the result determines the success or failure of the prepare phase of the global transaction. This option offers some performance benefits and greater data safety than Emulate Two-Phase Commit, but it has some limitations.

·         Emulate Two-Phase Commit: With this option, the transaction branch in which the connection is used always returns success for the prepare phase of the transaction. It offers performance benefits, but also has risks to data in some failure conditions. Select this option only if your application can tolerate heuristic conditions.

·         One-Phase Commit: (selected by default) with this option, a connection from the data source can be the only participant in the global transaction and the transaction is completed using a one-phase commit optimization. If more than one resource participates in the transaction, an exception is thrown when the transaction manager calls XAResource.prepare on the 1PC resource.

2) XA Transactions – XA is a distributed transaction, also called a global transaction. Distributed transaction is a transaction that accesses and updates data on two or more networked resource WebLogic Server user Java Transaction API (JTA) to implement the distributed Transactions.

Global transaction achieves atomicity. In other words, each operation in the series must succeed for the entire transaction to be successful. If any operation in the transaction does not succeed, the entire transaction fails. At that point, any operations which have succeeded must be "rolled back" so that the end state matches what was in place before the transaction started. Global Transaction by default uses two-phase commit protocol to achieve atomicity.

Two Phase Commit: In the first phase, checks are made to see if the transaction ran without error for all the network resources involved in the transaction. If no errors, the results are committed for all the resources in the second phase. If there are errors in the first-phase check for any of the resources, the transaction is rolled back. This common transaction strategy is appropriately called the two-phase commit protocol.

Note: When we have a local Transaction (Non-XA) in between two global transaction(XA) calls, distributed transaction branch suspends, lets the same connection do a local transaction, and then resumes the branch later. The two-phase commit actions of distributed transaction do not affect the local transaction.

Java Transaction API(JTA):

The Java Transaction API (JTA) gives you the ability to perform distributed transactions, that is, an application can use the API to perform transactions on more than one data store in the network at the same time. But to do this efficiently, it helps to have another component operating in the application server: a transaction manager. A transaction manager helps to efficiently schedule and execute the potentially large number of transactions coming in through the application server.

I always wanted to know little deeper on how the JTA works. So here is some information about the methods that are invoked during global transaction.

XA transactions need a global transaction id and local transaction id(xid) for each XA resource. Each XA Resource is enlisted to XA Manager by start(xid) method. This method tells that XA Resource is being involved in the transaction(be ready for operations). After that, the first phase of the 2PC protocol is realized by calling prepare(xid) method. This method requests OK or ABORT vote from XA Resource. After receiving vote from each of XA Resource, XA Manager decides to execute a commit(xid) operation if all XA Resources send OK or decides to execute a rollback(xid) if an XA Resource sends ABORT. Finally, the end(xid) method is called for each of XA Resource telling that the transaction is completed. 

To learn more on SOA Transaction timeouts, please visit the link. http://pruthvisoa.blogspot.com/2018/08/soa-transaction-timeout-settings.html