spring-framework / org.springframework.transaction.jta

Package org.springframework.transaction.jta

Types

JtaAfterCompletionSynchronization

open class JtaAfterCompletionSynchronization : Synchronization

Adapter for a JTA Synchronization, invoking the afterCommit / afterCompletion callbacks of Spring TransactionSynchronization objects callbacks after the outer JTA transaction has completed. Applied when participating in an existing (non-Spring) JTA transaction.

ManagedTransactionAdapter

open class ManagedTransactionAdapter : Transaction

Adapter for a managed JTA Transaction handle, taking a JTA javax.transaction.TransactionManager reference and creating a JTA javax.transaction.Transaction handle for it.

SimpleTransactionFactory

open class SimpleTransactionFactory : TransactionFactory

Default implementation of the TransactionFactory strategy interface, simply wrapping a standard JTA javax.transaction.TransactionManager.

Does not support transaction names; simply ignores any specified name.

SpringJtaSynchronizationAdapter

open class SpringJtaSynchronizationAdapter : Synchronization

Adapter that implements the JTA javax.transaction.Synchronization interface delegating to an underlying Spring org.springframework.transaction.support.TransactionSynchronization.

Useful for synchronizing Spring resource management code with plain JTA / EJB CMT transactions, despite the original code being built for Spring transaction synchronization.

UserTransactionAdapter

open class UserTransactionAdapter : UserTransaction

Adapter for a JTA UserTransaction handle, taking a JTA javax.transaction.TransactionManager reference and creating a JTA javax.transaction.UserTransaction handle for it.

The JTA UserTransaction interface is an exact subset of the JTA TransactionManager interface. Unfortunately, it does not serve as super-interface of TransactionManager, though, which requires an adapter such as this class to be used when intending to talk to a TransactionManager handle through the UserTransaction interface.

Used internally by Spring's JtaTransactionManager for certain scenarios. Not intended for direct use in application code.

WebLogicJtaTransactionManager

open class WebLogicJtaTransactionManager : JtaTransactionManager

Special JtaTransactionManager variant for BEA WebLogic (9.0 and higher). Supports the full power of Spring's transaction definitions on WebLogic's transaction coordinator, beyond standard JTA: transaction names, per-transaction isolation levels, and proper resuming of transactions in all cases.

Uses WebLogic's special begin(name) method to start a JTA transaction, in order to make Spring-driven transactions visible in WebLogic's transaction monitor. In case of Spring's declarative transactions, the exposed name will (by default) be the fully-qualified class name + "." + method name.

Supports a per-transaction isolation level through WebLogic's corresponding JTA transaction property "ISOLATION LEVEL". This will apply the specified isolation level (e.g. ISOLATION_SERIALIZABLE) to all JDBC Connections that participate in the given transaction.

Invokes WebLogic's special forceResume method if standard JTA resume failed, to also resume if the target transaction was marked rollback-only. If you're not relying on this feature of transaction suspension in the first place, Spring's standard JtaTransactionManager will behave properly too.

By default, the JTA UserTransaction and TransactionManager handles are fetched directly from WebLogic's TransactionHelper. This can be overridden by specifying "userTransaction"/"userTransactionName" and "transactionManager"/"transactionManagerName", passing in existing handles or specifying corresponding JNDI locations to look up.

NOTE: This JtaTransactionManager is intended to refine specific transaction demarcation behavior on Spring's side. It will happily co-exist with independently configured WebLogic transaction strategies in your persistence provider, with no need to specifically connect those setups in any way.

WebSphereUowTransactionManager

open class WebSphereUowTransactionManager : JtaTransactionManager, CallbackPreferringPlatformTransactionManager

WebSphere-specific PlatformTransactionManager implementation that delegates to a com.ibm.wsspi.uow.UOWManager instance, obtained from WebSphere's JNDI environment. This allows Spring to leverage the full power of the WebSphere transaction coordinator, including transaction suspension, in a manner that is perfectly compliant with officially supported WebSphere API.

The CallbackPreferringPlatformTransactionManager interface implemented by this class indicates that callers should preferably pass in a TransactionCallback through the #execute method, which will be handled through the callback-based WebSphere UOWManager API instead of through standard JTA API (UserTransaction / TransactionManager). This avoids the use of the non-public javax.transaction.TransactionManager API on WebSphere, staying within supported WebSphere API boundaries.

This transaction manager implementation derives from Spring's standard JtaTransactionManager, inheriting the capability to support programmatic transaction demarcation via getTransaction / commit / rollback calls through a JTA UserTransaction handle, for callers that do not use the TransactionCallback-based #execute method. However, transaction suspension is not supported in this getTransaction style (unless you explicitly specify a #setTransactionManager reference, despite the official WebSphere recommendations). Use the #execute style for any code that might require transaction suspension.

This transaction manager is compatible with WebSphere 6.1.0.9 and above. The default JNDI location for the UOWManager is "java:comp/websphere/UOWManager". If the location happens to differ according to your WebSphere documentation, simply specify the actual location through this transaction manager's "uowManagerName" bean property.

NOTE: This JtaTransactionManager is intended to refine specific transaction demarcation behavior on Spring's side. It will happily co-exist with independently configured WebSphere transaction strategies in your persistence provider, with no need to specifically connect those setups in any way.