Master Spring Transaction Abstraction: Platform & Reactive Managers

Environment: Spring 5.3.25

Understanding Spring Transaction Abstraction

Spring's transaction abstraction revolves around the concept of a transaction strategy defined by TransactionManager, especially the PlatformTransactionManager interface for imperative transactions and ReactiveTransactionManager for reactive transactions. The PlatformTransactionManager API includes methods getTransaction, commit, and rollback.

<code>public interface PlatformTransactionManager extends TransactionManager {
    TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException;
    void commit(TransactionStatus status) throws TransactionException;
    void rollback(TransactionStatus status) throws TransactionException;
}</code>

This is a Service Provider Interface (SPI) that can be programmatically used and easily mocked. It is not bound to a lookup strategy like JNDI and behaves like any other bean in the Spring IoC container.

Methods of PlatformTransactionManager throw unchecked TransactionException (subclass of RuntimeException). Transaction failures are usually fatal, though developers may catch TransactionException if desired.

The getTransaction method returns a TransactionStatus object, which may represent a new or existing transaction depending on the current call stack.

Since Spring 5.2, reactive applications can use ReactiveTransactionManager, whose API is shown below.

<code>public interface ReactiveTransactionManager extends TransactionManager {
    Mono<ReactiveTransaction> getReactiveTransaction(TransactionDefinition definition) throws TransactionException;
    Mono<Void> commit(ReactiveTransaction status) throws TransactionException;
    Mono<Void> rollback(ReactiveTransaction status) throws TransactionException;
}</code>

TransactionDefinition specifies attributes such as Propagation, Isolation, Timeout, and Read-Only, reflecting standard transaction concepts.

TransactionStatus provides methods to query and control transaction execution, as illustrated:

<code>public interface TransactionStatus extends TransactionExecution, SavepointManager, Flushable {
    boolean isNewTransaction();
    boolean hasSavepoint();
    void setRollbackOnly();
    boolean isRollbackOnly();
    void flush();
    boolean isCompleted();
}</code>

Choosing the correct TransactionManager implementation (JDBC, JTA, Hibernate, etc.) is essential and is usually defined via dependency injection.

Example XML bean definitions for a DataSource and a PlatformTransactionManager using HikariCP and DataSourceTransactionManager are provided, along with equivalent Java @Bean configurations.

For Hibernate, a LocalSessionFactoryBean and HibernateTransactionManager are defined, referencing the DataSource and SessionFactory respectively.

Synchronizing Resources with Transactions

Spring offers high‑level template‑based APIs or transaction‑aware factory beans to manage resource creation, reuse, cleanup, and optional transaction synchronization, so application code does not need to handle these concerns directly.

Low‑level utilities such as DataSourceUtils, EntityManagerFactoryUtils, and SessionFactoryUtils can be used when direct handling of native persistence APIs is required.

Example of obtaining a JDBC connection via DataSourceUtils:

<code>Connection conn = DataSourceUtils.getConnection(dataSource);</code>

TransactionAwareDataSourceProxy can wrap a target DataSource to add transaction awareness, though it is rarely needed when using Spring’s higher‑level abstractions.

Declarative Transaction Management

Spring implements declarative transaction management using AOP. TransactionAdvice driven by metadata (XML or annotations) creates an AOP proxy that applies TransactionInterceptor with the appropriate TransactionManager.

TransactionInterceptor selects the transaction manager based on the method’s return type: reactive types use ReactiveTransactionManager, while others use PlatformTransactionManager.

@Transactional typically uses a thread‑bound transaction managed by PlatformTransactionManager; it does not propagate to newly started threads. Reactive transactions managed by ReactiveTransactionManager use the Reactor context instead of thread‑local storage.

An example XML configuration shows how to define a tx:advice, tx:attributes, and aop:config to apply transactional advice to a FooService.

Rollback rules can be configured via rollback-for and no-rollback-for attributes in XML or corresponding annotation attributes, allowing fine‑grained control over which exceptions trigger a rollback.

Programmatic rollback can be performed by calling TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() within catch blocks.

Finally, the article includes two illustrative diagrams.