Understanding Spring Declarative Transaction Propagation and Isolation Levels

Spring's transaction mechanism consists of declarative (annotation‑based) and programmatic approaches; this article focuses on declarative transactions, which free developers from manually handling connections, commits, rollbacks, and try‑catch‑finally blocks.

Key transaction attributes are defined by the TransactionDefinition interface and include propagation behavior, isolation level, timeout, and read‑only flag. These attributes are used by the PlatformTransactionManager to control transaction boundaries.

public interface TransactionDefinition {
    int getPropagationBehavior(); // transaction propagation behavior
    int getIsolationLevel();      // isolation level
    int getTimeout();            // timeout in seconds
    boolean isReadOnly();        // read‑only flag
}

The five isolation levels correspond to JDBC standards:

ISOLATION_DEFAULT : uses the database's default isolation.

ISOLATION_READ_UNCOMMITTED : allows dirty reads.

ISOLATION_READ_COMMITTED : prevents dirty reads but may allow non‑repeatable and phantom reads.

ISOLATION_REPEATABLE_READ : prevents dirty and non‑repeatable reads, may still allow phantom reads.

ISOLATION_SERIALIZABLE : highest isolation, prevents all three anomalies.

Spring supports seven propagation behaviors. Examples:

PROPAGATION_REQUIRED – join an existing transaction or start a new one if none exists.

// PROPAGATION_REQUIRED example
methodA(){
    // ...
    methodB(); // joins the same transaction
}

methodB(){
    // ...
}

PROPAGATION_SUPPORTS – execute within a transaction if present; otherwise run non‑transactionally.

// PROPAGATION_SUPPORTS example
methodA(){
    methodB(); // runs non‑transactionally when no outer transaction
}

methodB(){
    // ...
}

PROPAGATION_MANDATORY – requires an existing transaction, otherwise throws an exception.

PROPAGATION_REQUIRES_NEW – suspends any existing transaction and starts a completely independent one.

// REQUIRES_NEW example (simplified)
main(){
    TransactionManager tm = getTransactionManager();
    tm.begin(); // outer transaction (ts1)
    // ...
    tm.suspend();
    tm.begin(); // inner transaction (ts2)
    methodB();
    tm.commit(); // commit ts2 independently
    tm.resume(ts1);
    // ...
    tm.commit(); // commit outer transaction
}

PROPAGATION_NOT_SUPPORTED – always executes non‑transactionally, suspending any existing transaction.

PROPAGATION_NEVER – always non‑transactional; throws an exception if a transaction is active.

PROPAGATION_NESTED – creates a real nested transaction using a JDBC savepoint; if the outer transaction rolls back, the nested one rolls back as well, but a failure in the nested transaction does not roll back the outer one.

// NESTED example (simplified)
main(){
    Connection con = getConnection();
    con.setAutoCommit(false);
    doSomeThingA();
    Savepoint sp = con.setSavepoint();
    try {
        methodB(); // runs in nested transaction
    } catch(RuntimeException e){
        con.rollback(sp); // rollback to savepoint only
    }
    doSomeThingB();
    con.commit();
}

Spring implements declarative transaction management using AOP; the framework automatically starts, commits, or rolls back transactions based on the defined attributes before and after method execution.

Understanding these propagation and isolation options enables developers to design robust transaction boundaries, avoid common anomalies such as dirty reads, non‑repeatable reads, and phantom reads, and choose the appropriate strategy for complex service interactions.