Java Transaction - JDBC, JTA, JTS
Concepts and implementation
Where these come from?
In transaction processing, there are several participants:
Resource Manager: like RDMS, JMS Providers(MQ), JCA Resources, transnational distributed systems
It is important to understand what constitutes a resource, in this context. For example, if you are using a JMS product, the JMS resource is the single running instance of the JMS product, not the individual queues and topics. Moreover, sometimes, what appears to be multiple resources might actually be a single resource, if the same underlying resource is accessed in different ways. For example, your application might access a relational database both directly (through JDBC) and indirectly (through an object-relational mapping tool like Hibernate). In this case, the same underlying transaction manager is involved, so it should be possible to enrol both of these code fragments in the same transaction.
Resource Adapters: JDBC drivers …
Transaction Manager: the part of an application that is responsible for coordinating transactions across one or more resources.
J2EE servers: EJB containers..
Of these, transaction manager is the core role. Two categories of transaction manager:
Local transaction manager:
a transaction manager that can coordinate transactions over a _single_ resource only. In this case, the implementation of the transaction manager is typically embedded in the resource itself.
For example, the Oracle database has a built-in transaction manager that supports demarcation operations (using SQL operations, BEGIN, COMMIT, ROLLBACK, or using a native Oracle API) and various levels of transaction isolation. Control over the Oracle transaction manager can be exported through JDBC, which is how Spring is able to abstract and wrap this kind of transaction manager as local transaction manager.
When we use resource local transaction in Java, we completely depend on database (a resource manager) to provide transaction support.
This is supported by JDBC API.
In the class Connection, there are several methods related to the resource local transaction:
setAutoCommit(boolean)
commit()
rollback()
setTransactionIsolation()
Global transaction manager:
A global transaction manager is a transaction manager that can coordinate transactions over _multiple_ resources. In this case, you cannot rely on the transaction manager built into the resource itself. Instead, you require an external system, sometimes called a transaction processing monitor (TP monitor), that is capable of coordinating transactions across different resources.
So the transactions coordinated by global transaction manager are called global transaction. And the transactions related with single resource and not coordinated by global transaction manager are called local transaction.
Unlike the above general concepts, in implementation and standard level of Java transaction support:
XA transaction is a kind of global distributed transaction which allow across multiple X/Open XA resources.
JTA support XA transaction and the related classes: UserTransaction, TransactionManager, XADataSource, XAResource, XAConnection.
JTA transaction manager is also a kind of global transaction manager, which usually runs in application server as a process and communicates with transaction participants during the two-phase commit protocol.
XA Transaction and XA Data source
The JTA allows distributed transactions across multiple X/Open XA resources. XA stands for Extended Architecture which was developed by the X/Open Group to define a transaction which uses more than one back-end data store. The XA standard describes the interface between a global Transaction Manager (TM) and a local resource manager. XA allows multiple resources, such as application servers, databases, caches, and message queues, to participate in the same transaction, while preserving atomicity of the transaction.
An XA datasource is a datasource which can participate in an XA global transaction.
2-Phase Commit Protocol
The Two-phase commit protocol (2PC) refers to the typical pattern of a database transaction.
In the first phase, the transaction participants notify the transaction manager whether they are able to commit the transaction or must roll back.
Java Transaction Service (JTS) is a mechanism for supporting Java Transaction API (JTA) transactions when participants of the transactions reside in multiple J2EE containers (application servers). In JTS transactions, the Transaction Coordinator manages interactions between transaction managers on different servers.
From an application standpoint, a JTS transaction behaves in the same ways as a JTA transaction. The difference is that transaction participants and datasources reside in different containers.
How JTA is supported?
The Java Transaction API consists of three elements: a high-level application transaction demarcation interface, a high-level transaction manager interface intended for an application server, and a standard Java mapping of the X/Open XA protocol intended for a transactional resource manager.
[javax.transaction.UserTransaction](http://docs.oracle.com/javaee/7/api/javax/transaction/UserTransaction.html), that is used by general client code such as a servlet or an EJB to manage the transactions, but it is usually acquired by JNDI reference (it should be available under java:comp/UserTransaction), and is usually injected into EJB when you use Container-Managed Transaction(CMT).
[javax.transaction.TransactionManager](http://docs.oracle.com/javaee/7/api/javax/transaction/TransactionManager.html), that is implemented by the application server itself to begin, commit and rollback the transactions.
[javax.transaction.xa.XAResource](http://docs.oracle.com/javaee/7/api/javax/transaction/xa/XAResource.html) interface is required to implement by each resource manager in order to be managed by the TP monitor. Each resource will have its own specific API, for instance:
- relational databases use JDBC (XADataSource, XAConnection are implemented by XA JDBC driver)
- messaging services use JMS
- generalized EIS (Enterprise Information System) resources use JCA (Java EE Connector API).
_If you are interested in how to implement a simple/naive transaction manager just like it’done in application server, please refer to:__http://blog.csdn.net/liu78778/article/details/4805308_
How can we use them in traditional J2EE enviorment?
UserTransaction support in servlet :
import javax.transaction.*；
import javax.naming.*；
// ...
InitialContext ctx = new InitialContext()；
Object txObj = ctx.lookup("java:comp/UserTransaction"；)；
UserTransaction utx = (UserTransaction) txObj；
utx.begin();
// ...
DataSource ds = obtainXADataSource();
Connection conn = ds.getConnection();
pstmt = conn.prepareStatement("UPDATE MOVIES ...");
pstmt.setString(1, "Spinal Tap");
pstmt.executeUpdate();
// ...
utx.commit();
UserTransaction support in EJB:
@Stateless
@TransactionManagement(BEAN)
public class ExampleBean {
@Resource
private UserTransaction utx;
public void foo() {
// start a transaction
utx.begin();
// Do work
// Commit it
utx.commit();
}
}
For more details, you need to refer to the EJB transaction management(CMT).
Spring transaction management abstraction
Spring intends to abstract these transaction management technology, and integrate them into a unified API.
PlatformTransactionManager is a service provider interface Spring provides. (NOTE, it’s not the subclass of javax.transaction.TransactionManager).
Currently, there are the following implementations:
Table 1 summarizes the local transaction manager implementations provided by the Spring framework. These transaction managers are distinguished by the fact that they support a _single resource only_.
Table 1. Local Transaction Managers
Table 2 summarizes the global transaction manager implementations provided by the Spring framework. These transaction managers are distinguished by the fact that they can support _multiple resources_.
Table 2. Global Transaction Managers