Transaction Management Strategies

Spring framework provides two primary strategies for managing transactional boundaries within an application: programmatic and declarative management. Programmatic management offers fine-grained control by allowing developers to explicitly demarcate transaction boundaries within the code, typically using the TransactionTemplate. In contrast, declarative management leverages Spring AOP (Aspect-Oriented Programming) to separate transaction logic from business logic. By using the @Transactional annotation, developers can define transaction behavior without invasive code changes, making it the preferred approach for most enterprise applications.

Programmatic Transaction Implementation

The core of programmatic transaction management revolves around the TransactionTemplate, which simplifies the interaction with the underlying PlatformTransactionManager. It implements the TransactionOperations interface, defining a standard execution contract.

public interface TxOps {
    @Nullable
    <T> T perform(TransactionCallback<T> action) throws TransactionException;
}

// Usage Example
TxOps template = new TxOps(transactionManager);
template.perform(status -> {
    // Business logic execution
    repository.updateData(data);
    return null;
});

Internally, the perform method retrieves a transaction status from the manager, executes the callback, and handles commit or rollback based on the outcome. If a RuntimeException or Error occurs, the transaction triggers a rollback; otherwise, it commits.

Declarative Transaction Configuration

To enable declarative transactions in Spring Boot, the @EnableTransactionManagement annotation is used, often imported via auto-configuration. The TransactionAutoConfiguration class sets up the necessary infrastructure beans. It registers a PlatformTransactionManager and configures the proxy mechanism. By default, Spring uses CGLIB proxying (proxyTargetClass = true) unless specified otherwise, allowing the interception of class-level methods directly.

The auto-configuration imports ProxyTransactionManagementConfiguration, which defines three critical components:

1. BeanFactoryTransactionAttributeSourceAdvisor: Acts as the advisor combining advice and pointcuts.
2. AnnotationTransactionAttributeSource: Parses @Transactional attributes from methods and classes.
3. TransactionInterceptor: The specific advice that intercepts method calls to manage transactions.

AOP Proxy Creation and Interception

Transaction management relies on AOP infrastructure. The InfrastructureAdvisorAutoProxyCreator (a BeanPostProcessor) intercepts bean initialization. It checks if a bean matches the transaction advisor's pointcut. If a match is found, the bean is wrapped in a proxy. When a proxied method is invoked, the call is routed to the TransactionInterceptor.

The TransactionInterceptor implements the MethodInterceptor interface. Its invoke method delegates to invokeWithinTransaction:

protected Object invokeWithinTransaction(Method method, Class<?> targetClass,
        InvocationCallback invocation) throws Throwable {

    TransactionAttribute txAttr = getTransactionAttributeSource().getTransactionAttribute(method, targetClass);
    PlatformTransactionManager tm = determineTransactionManager(txAttr);

    if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
        // Standard transaction flow
        TxInfo txInfo = createTxIfNecessary(tm, txAttr, methodIdentification(method, targetClass, txAttr));
        Object retVal;
        try {
            retVal = invocation.proceedWithInvocation();
        }
        catch (Throwable ex) {
            completeTxAfterThrowing(txInfo, ex);
            throw ex;
        }
        finally {
            cleanupTxInfo(txInfo);
        }
        commitTxAfterReturning(txInfo);
        return retVal;
    }
    // ... Programmatic handling
}

Transaction Lifecycle and Propagation

The PlatformTransactionManager is the core abstraction handling the transaction lifecycle. Its implementation, DataSourceTransactionManager, manages JDBC connections.

1. Transaction Acquisition (getTransaction)

This method determines if a transaction already exists based on the thread-bound connection.

• If a transaction exists: Behavior depends on the Propagation setting (e.g., MANDATORY throws an exception; REQUIRES_NEW suspends the current one and starts a new one).
• If no transaction exists: REQUIRED, REQUIRES_NEW, or NESTED will trigger doBegin to create a new transaction. This involves acquiring a database connection, setting auto-commit to false, and binding the connection holder to the current thread via TransactionSynchronizationManager.

For NESTED propagation, Spring creates a savepoint within the existing connection rather than a new physical transaction, allowing partial rollbacks.

2. Commit Process

The commit method checks the transaction status. If the transaction is marked for rollback-only, it performs a rollback. Otherwise, it triggers processCommit. If the transaction is new, it calls doCommit, which executes connection.commit(). Finally, resources are cleared and suspended transactions are resumed.

3. Rollback Process

Upon an exception, rollback is invoked. If the transaction has a savepoint (nested), it rolls back to that point. If it is a new transaction, it calls doRollback (connection.rollback()). If participating in an existing transaction, it typically marks the transaction as rollback-only, allowing the initiator to handle the physical rollback.

Concurrency: Integrating Distributed Locks with Transactions

A common pitfall in high-concurrency systems involves the interaction between distributed locks (e.g., Redisson) and database transactions.

The Issue: If a lock is acquired inside a transaction method, the lock might be released before the database transaction actually commits. This occurs because the proxy wraps the method; the lock is released in the finally block at the end of the method, but the database commit happens after the method returns. This creates a window where a second thread acquires the lock and reads stale data before the first thread's commit is flushed to the database.

Incorrect Implementation:

@Transactional
public void updateInventory(int itemId, int qty) {
    Lock lock = redisClient.getLock("item_lock_" + itemId);
    lock.lock();
    try {
        int current = inventoryRepo.getQuantity(itemId);
        inventoryRepo.updateQuantity(itemId, current + qty);
    } finally {
        lock.unlock(); // Lock released here, before DB commit!
    }
}

Solution: Acquire the lock in an external method and then invoke the transactional method via the proxy context. This ensures the transaction commits (or rolls back) before the lock is released.

public void safeUpdateInventory(int itemId, int qty) {
    Lock lock = redisClient.getLock("item_lock_" + itemId);
    if (lock.tryLock()) {
        try {
            // Invoke the transactional method via proxy to ensure TX context
            ((ServiceProxy) AopContext.currentProxy()).processUpdate(itemId, qty);
        } finally {
            lock.unlock(); // Lock released only after TX commits
        }
    }
}

@Transactional
public void processUpdate(int itemId, int qty) {
    int current = inventoryRepo.getQuantity(itemId);
    inventoryRepo.updateQuantity(itemId, current + qty);
}