If your application implements usecases that require support for global transactions (like moving data between two or more databases, or from a queue to a database, etc) then you need to run your app within an environment wich provides support for distributed transactions. Application servers are the usual candidates for such requirements since they implement the 2PC protocol out of the box. The second thing your application needs is to get �a handle� on the transaction manager in order to globally demarcate your transactions. As an example consider the
EJB programmers using BMT for implementing the transaction management. They will lookup up the
UserTransaction object from jndi and will call methods like
begin(), commit(), rollback() etc. Obviously Spring applications usually don�t know (and they shouldn�t) about the transaction manager used. Besides the whole point here is to use declarative security with Spring (via AOP).
That being said all you need to do is to tell spring about the transaction manager it should use to demarcate your transactions (AOP instead will border your code with similar code that the EJB-BMT programmers use). The
org.springframework.transaction.jta.JtaTransactionManager should be used when you intend to use global transactions. Here there is a configuration snippet I use with WAS (I hope it is self descriptive):
However not all applications have a need for global transactions. Many of them will only require managing data within a single persistence storage. If that�s the case you could also chouse to use
org.springframework.jdbc.datasource.DataSourceTransactionManager As for the last one
org.springframework.orm.hibernate.HibernateTransactionManager this works best with Hibernate applications (Spring integrates great with Hibernate). This also doesn�t provide support for global transactions. In a way you could think about this manager like a Hibernate customized version of the DataSourceTransactionManager.
Regards.
