Show Table of Contents
2.2. Spring Transaction Architecture
Figure 2.1, “Spring Transaction Architecture” shows an overview of the Spring transaction architecture.
Figure 2.1. Spring Transaction Architecture
Standalone Spring container
In the standalone deployment model, the Spring container 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.
Spring supports a variety of different wrapper APIs for accessing persistent storage. For example, to access a database through JDBC, Spring provides the
SimpleDriverDataSourceclass to represent the database instance and the
JdbcTemplateclass 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
DataSourceTransactionManagerfor JDBC, a
JmsTransactionManagerfor JMS, a
HibernateTransactionManagerfor Hibernate, and so on.