Distributed Transactions

The goal

The goal of transactions is to maintain data integrity & consistency  in case of concurrent accesses to data (e.g. multiple web sessions update the same database) and/or distributed resources (e.g. sending data to multiple databases/JMS resources). Typically a transaction has the ACID (atomic, consistent, isolated, and durable) properties in order to guarantee data integrity. 

X/Open Distributed Transaction Processing (DTP) standard

This is a popular distributed transaction standard. The architecture diagram (from Kosaraju, javaworld.com):

The Transaction Manager manages the transaction: manage transaction context, maintain associations with participating resources, conduct 2PC and recovery protocol. You can use open source transaction manager such as Atomikos. Transaction manager is also included in enterprise platforms such as Weblogic.

The Resource manager is a wrapper over a resource (e.g. database, JMS message broker) that implements XA interface for participating in transactions with a transaction manager. The transaction manager keeps track which resources that are participating in the transaction using resource enlistment process. For example in the case of Oracle database you get the resource manager by using an XA capable Oracle JDBC database driver.

TX interface is the interface between your application and the transaction manager. The important methods in this interface are such as for transaction demarcation  (e.g. begin, rollback, commit).

XA interface is the interface between resource managers and the transaction manager. The important methods in this interface are such as start, end, prepare (the first phase of 2PC), and commit  (the second phase of 2PC),.

For more details please read the article by Allamaraju (see the references below.)

Java Transaction API (JTA) and Java Transaction Service (JTS)

The architecture diagram (by Allamaraju):

In this transaction management from Sun, the API (JTA) follows the X/Open DTP interfaces while the transaction manager (JTS) implements the OMG OTS specification. OMG Object Transaction Service (OTS) standard is basically an X/Open DTP with additional features such as CORBA interfaces, nested transactions/finer granularity, synchronization protocol.

2PC (two-phase commit) protocol

This is a type of distributed transaction protocol to achieve data integrity. First the transaction manager issues prepare requests to all resource managers. If all the resource managers ready to commit (thus a kind of voting), the transaction manager will issue the commit request otherwise the transaction manager will issue the rollback.

Java examples:

Oracle JDBC XA driver

In the application, programmatically you can implement 2PC voting by using the statuses returned by resource managers after you call prepare() to all the resource manager via XA interface. Based on this voting you can perform either commit() or rollback() for all resource managers. An example of code (Oracle JDBC): http://docs.oracle.com/cd/E11882_01/java.112/e16548/xadistra.htm#autoId18

Spring with open sources JTA

Spring offer an extra abstraction layer for loose coupling between transaction management implementations & resources (JTA implementations (such as Atomikos, JBossTS), JPA/EJB3, Hibernate, single JDBC, JMS) and the application you write.

Kosaraju wrote a good article (with sample codes) about XA-2PC transaction examples in Spring using open sources JBossTS (usecase: 2 databases) and Atomikos (usecase: 1 database + 1 JMS/ActiveMQ): http://www.javaworld.com/javaworld/jw-04-2007/jw-04-xa.html

This is the sequence diagram (by Kosaraju) of the Atomikos case:

Rather than programmatic, you can better implement transaction using declarative way (either with annotation or AOP) since transaction management is a cross cutting concern across your applications and can be separated from your core business logic. It's interesting how Spring's declarative transaction,  transaction template and the transaction manager hide the complexities of programmatic transaction. In the sequence diagram above, the proxy (which is created by declarative transaction) invokes the transaction manager TX interface (doBegin, do Commit). We see also how the XA interface methods (start, end, prepare, commit) are used in the XA resources (database, jms).

While 2PC provides data integrity, its performance is expensive. You may trade off the data integrity for performance using relaxations of XA-2PC (e.g. XA-1PC, XA-Last resource) or non XA (Shared resource, Best effort 1PC). Please read (with sample codes): http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html

If you need to learn the basic of Spring transaction (with IoC, annotations, AOP, templates), please read the chapter 16 of the "Spring Recipes" book (with example codes).

Source: Steve's blogs http://soa-java.blogspot.com/

Any comments are welcome :)

---

Reference:

Nuts and Bolts of Transaction Processing by Allamaraju
http://www.subbu.org/articles/transactions/NutsAndBoltsOfTP.html
http://www.subbu.org/articles/jts/JTS.html


Spring Recipes by Mak



Java Transaction Processing





Java Transaction Design Patterns

XA transactions using Spring by Kosaraju
http://www.javaworld.com/javaworld/jw-04-2007/jw-04-xa.html

Distributed transactions in Spring, with and without XA by Syer
http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html

Oracle Database JDBC Developer's Guide
http://docs.oracle.com/cd/E11882_01/java.112/e16548/xadistra.htm#autoId18