sdjpa4-demo/transactions/docs/03-rollback.md

← Propagation · Index · NESTED and JPA →

3. Rollback, and the exception that appears from nowhere

Transcript: 02-rollback.txt.

Does the inner work survive the caller's rollback?

REQUIRED inner, outer rolls back        rows: 0   inner work rolled back
REQUIRES_NEW inner, outer rolls back    rows: 1   inner work SURVIVED

That is the entire reason REQUIRES_NEW exists. Audit rows, outbox entries and "we tried and it failed" records need to survive the failure that produced them, and only an independent physical transaction can do that.

UnexpectedRollbackException

The one worth understanding before it happens at 3am:

REQUIRED inner throws, outer catches it
    outcome : UnexpectedRollbackException
    message : Transaction silently rolled back because it has been marked as rollback-only
    rows    : 0

The sequence:

1. Outer method starts a transaction and calls an inner REQUIRED method.
2. The inner method throws. Its interceptor sees a RuntimeException — but it is participating in the caller's transaction, so it cannot roll back on its own. It sets rollback-only on the shared transaction and rethrows.
3. The outer method catches the exception and returns normally, believing it handled the failure.
4. The outer interceptor tries to commit. The transaction is marked rollback-only, so it rolls back and throws UnexpectedRollbackException.

Catching the exception did not save the work. It moved the failure to the commit boundary, where the stack trace has nothing to do with the original cause.

With REQUIRES_NEW, the same code behaves the way it reads: the inner transaction rolled back independently and the caller's catch worked.

If you must catch and continue, the inner call has to be REQUIRES_NEW. No amount of exception handling in the caller fixes a REQUIRED inner scope, because the damage is a flag set on a transaction the caller shares.

What triggers a rollback

By default: RuntimeException and Error. Not checked exceptions.

@Transactional(rollbackFor = Exception.class)          // roll back on checked too
@Transactional(noRollbackFor = NotFoundException.class) // and the reverse

The default comes from EJB and surprises almost everyone the first time. A method that declares throws IOException and throws it will commit — see chapter 5, failure 3.

Changing the default globally, new in Spring 7

@EnableTransactionManagement gained a rollbackOn() attribute taking a new RollbackOn enum:

@EnableTransactionManagement(rollbackOn = RollbackOn.ALL_EXCEPTIONS)

Two constants: RUNTIME_EXCEPTIONS (the historical behaviour) and ALL_EXCEPTIONS.

Note where it lives. Disassembling org.springframework.transaction.annotation.Transactional in spring-tx 7.0.9 shows twelve attributes and no rollbackOn among them, so this is a configuration-level switch rather than a per-method one. Per-method control is still rollbackFor / noRollbackFor.

If checked exceptions committing has bitten you before, this is the switch to flip once rather than the annotation to remember on every method.

Marking rollback-only yourself

TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

Honest when you want to abandon the transaction without throwing — but the caller then gets UnexpectedRollbackException at commit, so make sure that is what you want.