1
0
Files
Ankur Mhatre 585eed4d57 Add the transactions module, and move the migration project under migration-behavior/
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
2026-09-08 16:47:51 +00:00
..

@Transactional: propagation, isolation, and the six silent failures

Companion project for @Transactional in Spring on ankurm.com.

Every row of the propagation matrix was produced by calling the method and asking the transaction manager what it did — not by reading the enum.

Versions

Spring Boot 4.1.1
Spring Framework 7.0.9
JDK Eclipse Temurin 25.0.4.1 (LTS)
Database H2 in-memory
Transaction manager JpaTransactionManager (Spring Boot's default for JPA)

Quickstart

export JAVA_HOME=/path/to/jdk-25
mvn -DskipTests package
./scripts/run-all.sh          # regenerate every transcript in docs/output/
mvn test                      # 19 contract tests

The application listens on 8081 so it can run alongside the other demos.

Endpoints

Endpoint Purpose
GET /tx/propagation all seven propagations, called with and without a caller's transaction
GET /tx/rollback does the inner write survive the caller's rollback?
GET /tx/silent the six failures, plus a control that works
GET /tx/nested-jdbc NESTED succeeding, on a JDBC transaction manager
GET /tx/isolation isolation and readOnly where they apply and where they are ignored

Options

Property Effect
--demo.nested-allowed=true replaces the transaction manager with one that has nestedTransactionAllowed=true, to show the second failure

Documentation

  1. What @Transactional actually does
  2. The seven propagation values
  3. Rollback, and the exception that appears from nowhere
  4. NESTED, and why it does not work with JPA
  5. Six ways @Transactional silently does nothing
  6. Isolation, read-only, and settings that are ignored

Captured output

File Produced by
00-versions.txt scripts/demo-versions.sh
01-propagation.txt scripts/demo-propagation.sh
02-rollback.txt scripts/demo-rollback.sh
03-nested.txt scripts/demo-nested.sh
04-silent-failures.txt scripts/demo-silent.sh
05-isolation.txt scripts/demo-isolation.sh

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. It works on DataSourceTransactionManager, because a savepoint is a JDBC concept.
  • Catching a REQUIRED inner failure does not save the transaction. The inner scope already marked it rollback-only, so the commit throws UnexpectedRollbackException from a place with no connection to the original cause.
  • A checked exception commits. So does a swallowed one. These two do not merely fail to start a transaction — they commit work the code was trying to abandon.