[← Rollback](03-rollback.md) · [Index](../README.md) · [Six silent failures →](05-six-silent-failures.md)

# 4. `NESTED`, and why it does not work with JPA

Transcript: [`03-nested.txt`](output/03-nested.txt).

`NESTED` is described everywhere as "uses savepoints, so the inner scope can roll back without
taking the outer transaction with it". That description is accurate and, on a stock Spring Boot
JPA application, unreachable.

## Attempt 1 — a normal Spring Boot JPA application

```
NestedTransactionNotSupportedException:
Transaction manager does not allow nested transactions by default -
specify 'nestedTransactionAllowed' property with value 'true'
```

A clear message naming the fix. So:

## Attempt 2 — do what the message says

```java
JpaTransactionManager manager = new JpaTransactionManager(factory);
manager.setNestedTransactionAllowed(true);
```

```
NestedTransactionNotSupportedException:
JpaDialect does not support savepoints - check your JPA provider's capabilities
```

A *different* message, from a second check, pointing at your JPA provider rather than at your
configuration.

It is not the provider. `JpaTransactionManager` obtains the savepoint manager from the object
the `JpaDialect` returns when it begins the transaction, and Hibernate's does not implement one.
Verified by disassembling `JpaTransactionManager$JpaTransactionObject`, where the second check
is `getEntityManagerHolder().getSavepointManager() == null`. No configuration clears it.

There is a trap inside the trap: constructing `JpaTransactionManager` by hand also discards the
`JpaDialect` Spring Boot would have supplied from the Hibernate vendor adapter, leaving the
no-op `DefaultJpaDialect`. That produces the same second message for a *different* reason, and
sends you looking at your database instead of at your `@Bean`.

## Attempt 3 — the same propagation on a JDBC transaction manager

```json
{
  "rowsVisibleInsideNestedScope": 2,
  "nestedScopeThrew": "nested scope fails",
  "rowsAfterNestedRollback": 1,
  "rowsAfterOuterCommit": 1,
  "surviving": ["outer-row"],
  "transactionManager": "DataSourceTransactionManager (not JpaTransactionManager)"
}
```

Two rows visible inside the nested scope; one after it rolls back; one after the outer
transaction commits — and the survivor is the outer row. That is savepoint semantics working
exactly as advertised.

A savepoint is a JDBC concept. `DataSourceTransactionManager` holds the JDBC connection and can
issue one. `JpaTransactionManager` holds an `EntityManager` and cannot.

The reference documentation does say `NESTED` works with JDBC resource transactions. What it
does not say is that the JPA path fails, twice, with two different messages, the second of
which blames your database.

## What to do instead

**Use `REQUIRES_NEW`.** It solves most of what people reach for `NESTED` to solve — "let this
part fail without losing everything" — at the cost of a second connection and independent
commit semantics.

The genuine difference: `REQUIRES_NEW` commits the inner work even if the outer transaction
later fails, while `NESTED` would have discarded it. If you need "roll back this part, keep the
rest, and still lose everything if the outer transaction fails", you need savepoints and
therefore JDBC.

Mixing two transaction managers over one `DataSource`, as
[`JdbcNestedService`](../src/main/java/com/ankurm/tx/service/JdbcNestedService.java) does, is a
demonstration and not a recommendation.