Propagation Behaviors

REQUIRED is the default propagation. If a transaction is already running, the method joins it; if none exists, Spring starts a new one. So the code always runs inside exactly one transaction.

REQUIRES_NEW always starts a brand-new, independent transaction. If a transaction is already running, Spring pauses (suspends) it, runs the new one on its own database connection, then resumes the old one.

SUPPORTS joins an existing transaction if one is active, otherwise runs without one. MANDATORY requires an active transaction and throws if none exists. NEVER requires that no transaction is active and throws if one exists.

REQUIRES_NEW opens a separate transaction that commits on its own, surviving an outer rollback. NESTED stays inside one transaction using a savepoint; nested work is lost if the outer rolls back. Use REQUIRES_NEW for truly independent commits, NESTED for partial rollback within one unit.

The inner failure marks the shared transaction rollback-only. Even though the outer swallowed the exception, when it tries to commit Spring refuses and throws UnexpectedRollbackException — the whole transaction rolls back.

Spring applies @Transactional through a proxy that wraps the bean. An internal call (this.method()) skips the proxy, so the transaction advice never runs. Fix it by calling through an injected bean reference so the call goes through the proxy.

NESTED runs inside the existing transaction but sets a savepoint first. If the nested part fails, Spring rolls back only to that savepoint, keeping the outer work. It is one physical transaction, not two.

SUPPORTS joins an existing transaction but starts none if there isn't one. NEVER throws if a transaction exists, else runs without one. NOT_SUPPORTED always runs without one — suspending any existing transaction rather than joining or failing.

They share one physical transaction and one JDBC Connection. Each @Transactional method is a separate logical scope, but nested REQUIRED scopes all map onto the single physical transaction, so they commit or roll back together.

REQUIRES_NEW is a fully independent transaction on its own connection that commits separately. NESTED is a savepoint inside the same transaction and connection — rolling it back undoes only to the savepoint, but it commits only when the outer transaction commits.

Use MANDATORY when a method must only run inside an existing transaction opened by its caller. If called with no active transaction, Spring throws IllegalTransactionStateException and the method body never runs.

NESTED needs JDBC savepoints. JpaTransactionManager does not support them by default, so it throws NestedTransactionNotSupportedException. Use DataSourceTransactionManager (or JdbcTransactionManager), which builds on plain JDBC connections and supports savepoints.

Spring's transaction manager unbinds the active connection from the thread (suspend), runs the method with a fresh non-transactional connection, then rebinds the original (resume). Reads inside can't see the outer transaction's uncommitted changes because they use a different connection.

Use REQUIRES_NEW when a piece of work must commit or roll back independently of the caller — like an audit log that should persist even if the main transaction fails. It suspends the current transaction and runs on a second, separate Connection.

Spring unbinds the outer transaction's Connection from the thread (stored in TransactionSynchronizationManager), obtains a new Connection for the inner transaction, runs it, then rebinds and resumes the outer one after the inner commits or rolls back.

NEVER guarantees the method runs with no active transaction, throwing IllegalTransactionStateException if one exists. NOT_SUPPORTED also runs non-transactionally but tolerates an existing transaction by suspending it instead of throwing.

Because REQUIRED joins any active transaction, the boundary is set by the outermost @Transactional call — usually the top-level service method (the unit of work). Everything it calls shares that transaction, so keep those methods focused and avoid slow I/O inside them.

Each request now holds two connections at once, so the pool can exhaust or deadlock under load. Also the inner tx can't see the outer's uncommitted rows/locks and may block. Mitigate by sizing the pool for nesting depth, keeping the inner tx tiny, or moving audit to an async/outbox path.

With SUPPORTS and no active transaction, the method runs without one, so there is no rollback, isolation is the connection default, and any read-only/isolation settings on the annotation are effectively ignored. Behavior differs depending on the caller.

NESTED gives cheap per-item rollback via savepoints within one transaction, but the whole batch is still one long transaction holding locks and one connection. Alternatives — chunked commits, REQUIRES_NEW per item, or idempotent retries — trade atomicity for shorter locks and independent durability.

Use NOT_SUPPORTED for a long read-only/reporting query called from within a transaction, so you don't hold the caller's transaction, locks, and connection open. Weigh connection-pool doubling, lost read-your-writes visibility, and proxy self-invocation.

Mark low-level operations MANDATORY so they must run inside a caller's transaction, and mark operations that must stay outside one NEVER. Both fail fast with IllegalTransactionStateException. The main limit: the checks only fire through the Spring proxy, so self-invocation bypasses them.