[← Propagation](02-propagation.md) · [Index](../README.md) · [NESTED and JPA →](04-nested-and-jpa.md)

# 3. Rollback, and the exception that appears from nowhere

Transcript: [`02-rollback.txt`](output/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.

```java
@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](05-six-silent-failures.md),
failure 3.

## Changing the default globally, new in Spring 7

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

```java
@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

```java
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.