Transactions
There are situations where one would want to apply multiple updates to a resource (like GemFire, a database, etc.) atomically. The cases where you have multiple operations where you want all of them to succeed or all of them to fail. In such cases, you perform the operations within a transaction.
Details about GemFire transactions are here .
Global Transactions
There are scenarios where you might have multiple distinct resources that need to be updated within a single transaction.
In such cases, you will need to use a Global Transaction Manager to coordinate between resources. Generally, application servers, such as Weblogic, provide a Global Transaction Manager that the applications can leverage.
As an example, let us say you have code similar to the below pseudocode:
public void send(){ // Perform DB operations customerTable.insert(...) orderTable.update(...) //Perform JMS operation jms.send(...) }
You have a bunch of database operations and a JMS operation that you want to execute together, atomically, so that the database and JMS stay in sync. In this case, you have two resources (the database and the JMS) that need to be coordinated by a Global Transaction Manager (Weblogic, WebsphereUOW, Atomikos etc). In other words, you have a distributed transaction.
Java Transaction API (JTA)
The JTA is a specification that Global Transactions Managers (like Weblogic) and resources such as databases, JMS, and similar may adhere to. As a result of this adherence to a common API. the Global Transaction manager knows how to communicate with the resources that it is managing. JTA uses the 2-Phase commit protocol, so all the parties involved understand how to handle the 2-Phase commit.
Below are the parties involved in a distributed transaction:
Types of resources
The JTA architecture requires the resources to be XaResources, meaning that they must implement the javax.transaction.xa.XAResource interface. XaResources are equipped to participate in a 2 Phase-commit.
Some resources are non-XAResources. Non-XAResources are not equipped to participate in a 2 Phase-commit. If a resource is a non-XAResource (like GemFire) then it has an option to register as a Synchronization with the Transaction Manager. Such non-XAResource must implement javax.transaction.synchronization . This interface has methods afterCompletion and beforeCompletion which will be called by the transaction manager.
2-Phase Commit
JTA uses a 2-Phase Commit protocol. The Transaction Manager executes a distributed transaction in two phases:
1. Prepare Phase:
The transaction manager requests each XAResource manager to prepare for the commit. Generally, in this phase, each resource manager gets the required locks and does conflict checking.
2. Commit Phase:
If all the resource managers reply with success for the "Prepare Phase", the transaction manager directs the resource managers to "Commit", this is when each XAResource commits. If any of the resource managers reported failure for the "Prepare" phase, then, in the commit phase, instead of committing, the transaction manager directs a rollback to all the XAResources.
GemFire as last-resource
Since GemFire is not a XAResource, it does not directly participate in the 2-phase commit process.
As mentioned earlier, the JTA transaction manager needs the resources it manages to be XAResources so that the resources understand the 2-Phase commit protocol. Hence, transaction Managers allow at most one of the resource to be a non-XAResource.
This one non-XAResource can register for Synchronization and it will be notified before and after the global transaction completes.
Once GemFire is registered as a last-resource, the transaction manager will first commit the GemFire resource and then commit other XAResources.
Steps to configure GemFire as last-resource can be found here .