Ankur Mhatre
585eed4d57
The repository now aggregates two independent modules. migration-behavior/ is the
original project, moved unchanged; it stays on Spring Boot 4.0.6 / JDK 21 because
that is what the four published migration articles were verified against, and
upgrading it would silently invalidate output they quote. The article-tagged trees
are untouched, so links into a tag are unaffected.
transactions/ Companion code for "@Transactional in Spring: Propagation, Isolation,
and the Six Ways It Silently Does Nothing". Spring Boot 4.1.1 / JDK 25.
Every row of the propagation matrix is produced by calling the method and asking the
transaction manager what it did. The transaction NAME is the exhibit: a scope that
joined reports its caller's name, a scope that started its own reports its own.
Three things the transcripts settle:
- Propagation.NESTED cannot be used with JpaTransactionManager. It fails twice,
with two different messages, the second of which blames your JPA provider. The
savepoint manager comes from the object the JpaDialect returns when it begins the
transaction, and Hibernate's does not implement one. It works on
DataSourceTransactionManager, because a savepoint is a JDBC concept -- shown
working there rather than only failing here.
- Catching a REQUIRED inner failure does not save the transaction. The inner scope
has already marked it rollback-only, so the commit throws
UnexpectedRollbackException from a place with no connection to the cause.
- A checked exception commits, and so does a swallowed one. Those two do not merely
fail to start a transaction; they commit work the code was abandoning.
19 contract tests, six captured transcripts, all regenerated by scripts/run-all.sh.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gip4srpzMwjgoba6uEfbr5
84 lines
3.4 KiB
Markdown
84 lines
3.4 KiB
Markdown
[← 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.
|