Figure 2.1, “Spring Transaction Architecture” shows an overview of the Spring transaction architecture.

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 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.

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.