Package org.springframework.transaction.jta

Class JtaTransactionManager

java.lang.Object
org.springframework.transaction.support.AbstractPlatformTransactionManager
org.springframework.transaction.jta.JtaTransactionManager
All Implemented Interfaces:
Serializable, InitializingBean, ConfigurableTransactionManager, TransactionFactory, PlatformTransactionManager, TransactionManager
public class JtaTransactionManager extends AbstractPlatformTransactionManager implements TransactionFactory, InitializingBean, Serializable
PlatformTransactionManager implementation for JTA, delegating to a backend JTA provider. This is typically used to delegate to a Jakarta EE server's transaction coordinator, but may also be configured with a local JTA provider which is embedded within the application.

This transaction manager is appropriate for handling distributed transactions, i.e. transactions that span multiple resources, and for controlling transactions on application server resources (e.g. JDBC DataSources available in JNDI) in general. For a single JDBC DataSource, DataSourceTransactionManager is perfectly sufficient, and for accessing a single resource with Hibernate (including transactional cache), HibernateTransactionManager is appropriate, for example.

For typical JTA transactions (REQUIRED, SUPPORTS, MANDATORY, NEVER), a plain JtaTransactionManager definition is all you need, portable across all Jakarta EE servers. This corresponds to the functionality of the JTA UserTransaction, for which Jakarta EE specifies a standard JNDI name ("java:comp/UserTransaction"). There is no need to configure a server-specific TransactionManager lookup for this kind of JTA usage.

Transaction suspension (REQUIRES_NEW, NOT_SUPPORTED) is just available with a JTA TransactionManager being registered. Common TransactionManager locations are autodetected by JtaTransactionManager, provided that the "autodetectTransactionManager" flag is set to "true" (which it is by default).

Note: Support for the JTA TransactionManager interface is not required by Jakarta EE. Almost all Jakarta EE servers expose it, but do so as extension to EE. There might be some issues with compatibility, despite the TransactionManager interface being part of JTA.

This pure JtaTransactionManager class supports timeouts but not per-transaction isolation levels. Custom subclasses may override the doJtaBegin(org.springframework.transaction.jta.JtaTransactionObject, org.springframework.transaction.TransactionDefinition) method for specific JTA extensions in order to provide this functionality. Such adapters for specific Jakarta EE transaction coordinators may also expose transaction names for monitoring; with standard JTA, transaction names will simply be ignored.

JTA 1.1 adds the TransactionSynchronizationRegistry facility, as public Jakarta EE API in addition to the standard JTA UserTransaction handle. As of Spring 2.5, this JtaTransactionManager autodetects the TransactionSynchronizationRegistry and uses it for registering Spring-managed synchronizations when participating in an existing JTA transaction (e.g. controlled by EJB CMT). If no TransactionSynchronizationRegistry is available, then such synchronizations will be registered via the (non-EE) JTA TransactionManager handle.

This class is serializable. However, active synchronizations do not survive serialization.

Since:
24.03.2003
Author:
Juergen Hoeller
See Also: