Spring Transactions: REQUIRES_NEW Suspension Semantics

`REQUIRES_NEW` suspends the current transaction and starts an independent transaction for the inner operation. The inner transaction commits or rolls back separately from the suspended outer transaction.

When a method using `@Transactional(propagation = Propagation.REQUIRES_NEW)` is invoked while another transaction is active, Spring suspends the existing transaction before starting a new one. The inner method therefore executes with its own transactional context.

The two transactions have independent commit and rollback outcomes. If the inner transaction commits successfully, its database changes can remain committed even when the outer transaction later rolls back. Conversely, an outer rollback does not automatically roll back a transaction that has already committed under `REQUIRES_NEW`.

Suspension also affects transaction-scoped resources such as the database connection associated with the transaction. The outer transaction's resources remain associated with the suspended transaction while the inner transaction obtains resources for its own work. This can increase connection usage and should be considered when configuring connection-pool capacity.

`REQUIRES_NEW` is useful when an operation must have an independent transaction boundary, such as recording an audit event that should survive failure of the surrounding business transaction. It should not be used merely as a generic way to avoid rollback, because it changes transaction boundaries and resource requirements.

Key points

• An active outer transaction is suspended before the `REQUIRES_NEW` transaction starts.
• The inner transaction has an independent commit and rollback outcome.
• An inner commit can survive a later outer rollback.
• The suspended transaction resumes after the inner transaction completes.
• Independent transactions can require additional database connections.

Interview questions

How does `REQUIRES_NEW` differ from `NESTED` propagation?

`REQUIRES_NEW` suspends the existing transaction and executes the inner work in a separate transaction. `NESTED` generally uses a savepoint within the existing transaction when the transaction manager and resource support it. Because a nested operation remains part of the outer transaction, its changes do not have the same independent commit semantics as `REQUIRES_NEW`. The distinction is important when deciding whether inner work must survive an outer rollback.

What happens when a `REQUIRES_NEW` method is called from an existing transaction?

Spring suspends the existing transaction before entering the `REQUIRES_NEW` method. It then starts a separate transaction for the inner operation. When the inner transaction completes, the suspended outer transaction is resumed. The two transactions therefore have separate commit and rollback outcomes.

Why might an audit record persist when the business transaction rolls back?

If the audit method uses `REQUIRES_NEW`, its work runs in a separate transaction. That transaction can commit before control returns to the outer transaction. If the outer transaction subsequently fails and rolls back, its rollback does not undo the already committed audit transaction. This makes `REQUIRES_NEW` useful for certain independent logging or auditing requirements.

What resource-management issue can `REQUIRES_NEW` introduce?

Suspending the outer transaction does not mean its resources necessarily disappear immediately. The outer transaction may retain its database connection while the inner transaction obtains another connection. Under concurrency, this can increase the number of simultaneously required connections. If the connection pool is too small, this can contribute to exhaustion or blocking.

What should you check if `REQUIRES_NEW` appears not to create a new transaction?

First, verify that Spring's transaction interceptor is actually being invoked. With proxy-based configuration, a method call made directly from another method on the same object can bypass the proxy and therefore bypass transactional interception. I would also verify the active transaction manager, proxy configuration, and transaction logs or transaction identifiers. The annotation itself does not guarantee a new transaction if the call never passes through the transaction interceptor.