CallbackPreferringPlatformTransactionManager

Extension of the org.springframework.transaction.PlatformTransactionManager interface, exposing a method for executing a given callback within a transaction.

Implementors of this interface automatically express a preference for callbacks over programmatic getTransaction, commit and rollback calls. Calling code may check whether a given transaction manager implements this interface to choose to prepare a callback instead of explicit transaction demarcation control.

Spring's TransactionTemplate and org.springframework.transaction.interceptor.TransactionInterceptor detect and use this PlatformTransactionManager variant automatically.

DefaultTransactionDefinition

Default implementation of the TransactionDefinition interface, offering bean-style configuration and sensible default values (PROPAGATION_REQUIRED, ISOLATION_DEFAULT, TIMEOUT_DEFAULT, readOnly=false).

Base class for both TransactionTemplate and org.springframework.transaction.interceptor.DefaultTransactionAttribute.

DelegatingTransactionDefinition

TransactionDefinition implementation that delegates all calls to a given target TransactionDefinition instance. Abstract because it is meant to be subclassed, with subclasses overriding specific methods that are not supposed to simply delegate to the target instance.

ResourceHolderSynchronization

TransactionSynchronization implementation that manages a ResourceHolder bound through TransactionSynchronizationManager.

SimpleTransactionScope

A simple transaction-backed Scope implementation, delegating to TransactionSynchronizationManager's resource binding mechanism.

NOTE: Like org.springframework.context.support.SimpleThreadScope, this transaction scope is not registered by default in common contexts. Instead, you need to explicitly assign it to a scope key in your setup, either through org.springframework.beans.factory.config.ConfigurableBeanFactory#registerScope or through a org.springframework.beans.factory.config.CustomScopeConfigurer bean.

SimpleTransactionStatus

A simple org.springframework.transaction.TransactionStatus implementation.

Derives from AbstractTransactionStatus and adds an explicit "newTransaction" flag.

This class is not used by any of Spring's pre-built org.springframework.transaction.PlatformTransactionManager implementations. It is mainly provided as a start for custom transaction manager implementations and as a static mock for testing transactional code (either as part of a mock PlatformTransactionManager or as argument passed into a TransactionCallback to be tested).

TransactionCallbackWithoutResult

Simple convenience class for TransactionCallback implementation. Allows for implementing a doInTransaction version without result, i.e. without the need for a return statement.

TransactionOperations

Interface specifying basic transaction execution operations. Implemented by TransactionTemplate. Not often used directly, but a useful option to enhance testability, as it can easily be mocked or stubbed.

TransactionSynchronizationUtils

Utility methods for triggering specific TransactionSynchronization callback methods on all currently registered synchronizations.

TransactionTemplate

Template class that simplifies programmatic transaction demarcation and transaction exception handling.

The central method is #execute, supporting transactional code that implements the TransactionCallback interface. This template handles the transaction lifecycle and possible exceptions such that neither the TransactionCallback implementation nor the calling code needs to explicitly handle transactions.

Typical usage: Allows for writing low-level data access objects that use resources such as JDBC DataSources but are not transaction-aware themselves. Instead, they can implicitly participate in transactions handled by higher-level application services utilizing this class, making calls to the low-level services via an inner-class callback object.

Can be used within a service implementation via direct instantiation with a transaction manager reference, or get prepared in an application context and passed to services as bean reference. Note: The transaction manager should always be configured as bean in the application context: in the first case given to the service directly, in the second case given to the prepared template.

Supports setting the propagation behavior and the isolation level by name, for convenient configuration in context definitions.