Transactions are a critical part of applications interacting with databases or other persistent resources. They ensure consistency, integrity, and reliability of data when multiple operations must succeed or fail as a unit. Spring provides advanced tools for transaction management, both declarative and programmatic, allowing developers to focus on business logic while ensuring transactional safety.

1. What is a Transaction?

A transaction is a sequence of operations that must be executed as a single, atomic unit of work. This means that either all operations succeed, or none are applied, maintaining the database in a consistent state.

Why Transactions are Important

Without transactions, if part of a multi-step operation fails, the system can end up in an inconsistent state. For example:

• Banking example: Transfer ₹500 from Alice to Bob. If Alice’s account is debited but Bob’s account isn’t credited due to an error, money is lost. A transaction ensures both steps succeed or none do.
• Inventory example: Deduct stock when an order is placed. If the payment succeeds but stock deduction fails, the system shows incorrect inventory levels.

ACID Properties

Transactions guarantee ACID properties to ensure reliability:

• Atomicity: Every operation in a transaction must complete successfully. If any operation fails, all operations are rolled back.
  Example: Updating two related tables in a database must either both succeed or both fail.
• Consistency: Transactions ensure that the database moves from one valid state to another. Integrity constraints are preserved.
  Example: Account balances cannot be negative. A transaction violating this constraint will be rolled back.
• Isolation: Concurrent transactions do not affect each other. Each transaction behaves as if it is the only one executing.
  Example: Two users updating the same bank account at the same time will not see partial updates.
• Durability: Once a transaction is committed, it persists permanently, even in the event of system crashes or power failures.
  Example: After a successful fund transfer, the database reflects the change permanently, regardless of server failures.

2. Transactions in Spring

Spring provides two primary ways to manage transactions:

1. Declarative Transaction Management: Define transactional behavior using annotations like @Transactional. This is simple and reduces boilerplate code.
2. Programmatic Transaction Management: Explicitly control transactions in code using TransactionTemplate or PlatformTransactionManager. This is more flexible and allows custom handling.

Spring handles transactions using Aspect-Oriented Programming (AOP):

• Spring creates a proxy object for transactional beans.
• Method calls to @Transactional methods are intercepted by a TransactionInterceptor.
• The interceptor delegates transaction management to the appropriate TransactionManager.
• After the method executes, the transaction is either committed if successful or rolled back in case of exceptions.

This approach eliminates repetitive boilerplate code and reduces human errors in handling transactions.

3. Why Use Spring Transactions?

Without Spring, developers need to manually manage transactions:

Connection conn = null;
try {
    conn = dataSource.getConnection();
    conn.setAutoCommit(false);
    // Business operations
    updateAccountBalance();
    logTransaction();
    conn.commit();
} catch(Exception e) {
    if (conn != null) conn.rollback();
}

Problems with manual transaction management:

• Verbose and repetitive: Every transactional method requires explicit commit and rollback.
• Error-prone: Missing rollback in exceptions can lead to inconsistent data.
• Difficult to maintain: Propagation and nested transaction handling must be implemented manually.

Spring solves this using @Transactional:

• Automatically handles commit and rollback.
• Supports custom rollback rules.
• Works seamlessly with JPA, Hibernate, JDBC, and JTA.
• Supports declarative propagation and isolation levels.

4. Transaction Manager in Spring

A TransactionManager coordinates transactions between your application and the underlying resource (usually a database). Spring provides different managers depending on your setup:

• JpaTransactionManager: For Spring Data JPA, Hibernate, or JPA-based repositories.
• DataSourceTransactionManager: For plain JDBC-based applications.
• JtaTransactionManager: For distributed/global transactions involving multiple resources.

Spring Boot can automatically detect and configure the correct transaction manager based on your dependencies.

If multiple transaction managers exist:

• Mark one as @Primary to make it the default.
• Use @Transactional(transactionManager = "beanName") to explicitly select the manager.

Example of Manual Transaction Manager Configuration

@Bean
public PlatformTransactionManager transactionManager(DataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
}

Benefits of configuring manually:

• Allows fine control over which data source is transactional in multi-datasource setups.
• Supports customized behavior for transaction propagation and isolation.

5. Declarative Transaction Management

Declarative transaction management is the preferred approach because it is less error-prone, easier to maintain, and integrates seamlessly with Spring’s AOP framework.

@Transactional Annotation

@Transactional(
    propagation = Propagation.REQUIRED,
    isolation = Isolation.READ_COMMITTED,
    timeout = 30,
    readOnly = false,
    rollbackFor = {CustomException.class}
)
public void processPayment() {
    // transactional business logic
}

Explanation of Properties:

• propagation: Determines how this transaction behaves if an existing transaction exists.
• isolation: Defines how visible this transaction’s changes are to others.
• timeout: Automatically rolls back if the transaction takes longer than specified seconds.
• readOnly: Optimizes the transaction for read-only operations; some databases may reduce locks.
• rollbackFor: Specifies exceptions (checked or unchecked) that trigger rollback.

Key Notes:

• By default, unchecked exceptions (RuntimeException) trigger rollback.
• Checked exceptions do not rollback unless explicitly specified.
• Declarative transactions are ideal for standard service-layer methods that need atomicity.

6. Programmatic Transaction Management

Programmatic transaction management provides fine-grained control but requires more code.

Example using TransactionTemplate

transactionTemplate.execute(status -> {
    try {
        updateAccountBalance();
        logTransaction();
    } catch (Exception e) {
        status.setRollbackOnly();
        throw e;
    }
    return null;
});

Advantages:

• Allows conditional transactional behavior.
• Supports nested transactions with separate rollback logic.
• Can handle complex scenarios where parts of a method require a transaction while others do not.

Disadvantages:

• Verbose and requires careful handling of exceptions.
• Mixing programmatic and declarative transactions can be confusing if not managed properly.

7. Transaction Propagation

Transaction propagation defines how methods interact with existing transactions. Spring defines seven propagation types:

1. REQUIRED (Default):
   • Joins an existing transaction if present; otherwise, starts a new one.
   • Example: Service A calls Service B; both should be atomic.
2. REQUIRES_NEW:
   • Suspends the current transaction and starts a new one.
   • Example: Logging actions must persist even if main transaction fails.
3. NESTED:
   • Creates a nested transaction if a parent exists; rollback of nested transaction does not affect the outer transaction.
   • Example: Processing multiple items in an order; if one fails, only that item’s transaction is rolled back.
4. MANDATORY:
   • Must run in an existing transaction; throws exception if none exists.
   • Example: A method that only makes sense in transactional context, like adjusting inventory after a confirmed order.
5. SUPPORTS:
   • Joins existing transaction if available; otherwise runs non-transactionally.
   • Example: Read-only queries that may or may not be part of a transaction.
6. NOT_SUPPORTED:
   • Runs without a transaction; suspends any existing transaction.
   • Example: Logging or notifications that should not be affected by the main transaction.
7. NEVER:
   • Must not run in a transactional context; throws exception if a transaction exists.
   • Example: High-performance operations where transactional overhead is unacceptable.

Tip: Understanding propagation types helps in designing robust multi-service or nested transaction scenarios.

8. Transaction Isolation

Isolation determines how concurrent transactions interact with each other. Without proper isolation, anomalies can occur:

Types of Concurrency Problems

1. Dirty Read:
   • Transaction reads uncommitted changes from another transaction.
   • Example: T1 updates a balance but hasn’t committed; T2 reads the incorrect value.
2. Non-repeatable Read:
   • Reading the same row twice yields different results because another transaction modified it.
   • Example: T1 reads a balance = 1000; T2 updates it to 1500; T1 reads again → 1500.
3. Phantom Read:
   • Running the same query twice returns different row sets due to insertions/deletions.
   • Example: T1 queries “users in Delhi” (10 rows); T2 adds a user; T1 sees 11 rows next query.

Isolation Levels

• READ_UNCOMMITTED: Allows dirty reads; highest concurrency but least protection.
• READ_COMMITTED: Prevents dirty reads; default in most databases.
• REPEATABLE_READ: Prevents dirty and non-repeatable reads.
• SERIALIZABLE: Prevents all anomalies but reduces concurrency and increases risk of deadlocks.

Database Defaults:

• MySQL (InnoDB): REPEATABLE_READ
• PostgreSQL, Oracle: READ_COMMITTED
• SQL Server: READ_COMMITTED

Rule of Thumb:

• Standard CRUD operations: READ_COMMITTED
• Financial or critical operations: REPEATABLE_READ or SERIALIZABLE

9. Concurrency Considerations

Even with transactions, concurrent operations can lead to unexpected behavior if propagation and isolation are misconfigured.

Best Practices:

• Use REQUIRED propagation for most service-layer methods.
• Use REQUIRES_NEW for independent actions like logging, auditing, or notifications.
• Carefully choose isolation levels depending on accuracy vs performance requirements.
• Avoid long-running transactions; they increase risk of deadlocks and blocking.
• Monitor transaction timeouts and rollback thresholds to prevent system bottlenecks.

10. Summary

Spring Transaction Management offers:

• Robust support for declarative and programmatic transactions.
• Automatic handling of commit and rollback.
• Fine-grained control through propagation, isolation, timeout, and read-only settings.
• Integration with JPA, Hibernate, JDBC, and distributed transactions.
• Tools to balance performance and data integrity.

Proper use of Spring transactions ensures data consistency, reliability, and maintainability, making applications resilient even under high concurrency.