Spring Transaction Architecture
Deployment options
As shown below, there are two fundamentally different ways of deploying an application that uses Spring transactions:
- Standalone Spring container
- J2EE container deployment
Standalone Spring container
In the standalone deployment model, the Spring container is provides access to persistent data sources and is responsible for managing the transactions associated with those data sources. A notable limitation of the standalone model is that the Spring container can support only local transaction managers, which means that only one data source (resource) at a time can participate in a transaction.
Data source
Spring supports a variety of different wrapper APIs for accessing persistent storage. For example, to access a database through JDBC, Spring provides the SimpleDriverDataSource class to represent the database instance and the JdbcTemplate class to provide access to the database using SQL. Wrappers are also provided for other kinds of persistent resource, such as JMS, Hibernate, and so on. The Spring data sources are designed to be compatible with the local transaction manager classes.
Local transaction manager
In Spring, a local transaction manager is a wrapper class that is responsible for managing the transactions of a single resource. The local transaction manager is responsible for starting, committing, and rolling back transactions. Typically, the way that you use a transaction manager in Apache Camel is that you pass the transaction manager reference to a transactional Apache Camel component bean.
Spring provides different types of local transaction manager for different types of data source. For example, Spring provides a DataSourceTransactionManager for JDBC, a JmsTransactionManager for JMS, a HibernateTransactionManager for Hibernate, and so on.
J2EE container deployment
In the J2EE deployment model, the Spring container is nested inside a J2EE application server. The advantage of this deployment model is that the Spring container can leverage the transaction management capabilities of the J2EE container. In particular, the Spring container can now access global transactions, which means that multiple resources can participate in a single transaction.
XA resources
In a J2EE deployment, the persistent resources should be integrated directly with J2EE. In other words, you do not use Spring data sources in this case. Moreover, in order to enable global transactions, you register each resource's XA interface with the JTA transaction manager in the J2EE environment.
JTA transaction manager
The Java Transaction API (JTA) and the Java Transaction Service define respectively the API and the implementation of a transaction manager for the J2EE platform. A full implementation of the JTA transaction manager can potentially provide enterprise-level transaction features, including support for global transactions, XA resources, and (in some cases) distributed transactions.
Global transaction manager
To access J2EE global transactions from within the Spring environment, the Spring container provides the JtaTransactionManager class, which is essentially just a thin wrapper around the JTA transaction manager. In fact, the JTA transaction manager is completely configured within the J2EE environment. If required, you can instantiate the Spring wrapper class, JtaTransactionManager, by obtaining a reference to the existing JTA transaction manager in J2EE, typically using a JNDI lookup.
For detail, open this url: