JTA GemFire Global Transaction Concepts
search cancel

JTA GemFire Global Transaction Concepts

book

Article ID: 294065

calendar_today

Updated On:

Products

VMware Tanzu Gemfire

Issue/Introduction

This article pertains to Pivotal Gemfire all supported versions

Resolution

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:

  • Your application
  • Transaction Manager (Generally provided by your application server, but can be standalone, like Atomikos) which implements javax.transaction.TransactionManager
  • Resource Adapter (Ex. database driver or the GemFire JCA .rar file in case of GemFire)
  • Resource Manager (your DBMS in case of DB or GemFire itself in case of GemFire) 

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 .

    Additional Information