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
2.8 KiB
6. Isolation, read-only, and settings that are ignored
Transcript: 05-isolation.txt.
The levels
| Level | Prevents | Cost |
|---|---|---|
READ_UNCOMMITTED |
nothing | lowest |
READ_COMMITTED |
dirty reads | low — the default on Postgres, SQL Server, Oracle |
REPEATABLE_READ |
dirty + non-repeatable reads | medium — the default on MySQL |
SERIALIZABLE |
all of the above + phantoms | highest |
ISOLATION_DEFAULT means "whatever the connection already has", which is the database's
default and not something Spring chooses.
Settings apply only where the transaction starts
The finding worth taking away:
@Transactional(isolation = SERIALIZABLE) [outer] isolation=SERIALIZABLE
REQUIRED inner joining it isolation=SERIALIZABLE
plain @Transactional [outer] isolation=default
inner declaring READ_UNCOMMITTED isolation=default
The inner method declares @Transactional(isolation = READ_UNCOMMITTED) and gets the default.
It joined an existing physical transaction, whose isolation was fixed when it began. The
declaration is not rejected, nothing is logged, and it simply has no effect.
The same is true of readOnly and timeout on a participating scope. All three are properties
of a physical transaction, and a participating scope does not have one of its own.
Confirmed in the transaction manager's own log: ISOLATION_SERIALIZABLE appears on
Creating new transaction lines and never on Participating in existing transaction lines,
because participation carries no settings.
Make it loud: set validateExistingTransaction=true on the transaction manager and a
mismatched declaration becomes an exception instead of a silent no-op. It is off by default.
readOnly does less than its name suggests
readOnly = true is a hint. It does not make the database reject writes. What it does:
- Sets the JDBC connection read-only flag, which some drivers act on and others ignore.
- Puts Hibernate's
FlushModetoMANUAL, so the persistence context does not dirty-check or flush — which is where the real performance benefit comes from on read paths. - Lets a routing datasource send the transaction to a replica.
A write inside a readOnly transaction may silently do nothing (never flushed) or may fail,
depending on the driver. "Silently does nothing" is the more common and more dangerous outcome,
and it is a genuine seventh entry for chapter 5's list.
timeout
Seconds, enforced by Spring for the operations it controls and passed to the JDBC statement timeout where supported. Applies only to a scope that starts a transaction — same rule as above.