sdjpa4-demo/transactions/docs/04-nested-and-jpa.md

← Rollback · Index · Six silent failures →

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

Transcript: 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

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

{
  "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 does, is a demonstration and not a recommendation.