Although transactionless architectures are gaining some ground as a way to overcome the scalability limitations inherent in classic distributed transactions, widely implemented standards make distributed transactions a natural a technique to employ when an enterprise application must modifies data in more than one resource.

The most popular distributed transaction standard is XA from the Open Group. In his recent JavaWorld article, XA Transactions Using Spring, Murali Kosaraju describes several Java XA transaction resources, and shows how to use them in Spring applications.

Distributed transactions following the two-phase commit protocol are typically driven by a transaction coordinator: The coordinator ensures that all transaction participants are prepared to commit a transaction and, second, that each participant commit the transaction. In case of a participant's failure to commit, the coordinator instructs all transaction participants to abort the transaction, causing each participant to roll back the changes it made to data.

Kosaraju's article describes the Java Transaction API, the Java standard that defines the interface between a distributed transaction coordinator and the transaction participants. He notes that part of the JTA standard provides a mapping between the XA transaction standard and Java-specific transaction participants.

The article then turns to using Spring in the context of distributed Java transactions:

Please note that Spring doesn't provide any JTA implementation as such. The only task from the user perspective is to make sure that the JTA implementation is wired to use the Spring framework's JTA support.

Kosaraju describes several JTA transaction manager implementations that can be wired into a Spring application:

JBossTS, formerly known as Arjuna Transaction Service, comes with a very robust implementation, which supports both JTA and JTS API. JBossTS comes with a recovery service, which could be run as a separate process from your application processes. Unfortunately, it doesn't support out-of-the box integration with Spring, but it is easy to integrate as we will see in our exercise. Also there is no support for JMS resources, only database resources are supported...

Atomikos's JTA implementation has been open sourced very recently... It is a production quality implementation, which also supports recovery and some exotic features beyond the JTA API. Atomikos provides out of the box Spring integration along with some nice examples. Atomikos supports both database and JMS resources. It also provides support for pooled connections for both database and JMS resources.

Bitronix's JTA implementation is fairly new and is still in beta. It also claims to support transaction recovery as good as or even better than some of the commercial products. Bitronix provides support for both database and JMS resources. Bitronix also provides connection pooling and session pooling out of the box.

The rest of Kosaraju's article focuses on how to use these JTA implementation in conjunction with Spring and two transactional resources: a MySQL database and ActiveMQ:

Apache's ActiveMQ provides the necessary implementation for handling XA transactions.... The MySQL database provides an XA implementation and works only for their InnoDB engines. It also provides a decent JDBC driver, which supports the JTA/XA protocol...

How often do you use distributed transactions in your applications? If you don't use distributed transactions, how do you ensure the ACID properties across multiple resources?