asmhatre/sdjpa4-demo
1
0
Fork 0
Code Activity

Add the transactions module, and move the migration project under migration-behavior/

Browse Source 
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
This commit is contained in:
Ankur Mhatre
2026-09-08 16:36:32 +00:00
parent 879a06929a
commit 585eed4d57
53 changed files with 2278 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
transactions/docs/output/04-silent-failures.txt Normal file
View File

@@ -0,0 +1,42 @@
== six pieces of code carrying @Transactional that are not transactional ==
Row 0 is the control: the SAME annotated method, reached through the proxy.
{
"0-control-through-the-proxy": "through the proxy: actualTransactionActive=true",
"1-self-invocation": "self-invocation: actualTransactionActive=false",
"2-private-method": "private method: actualTransactionActive=false",
"3-checked-exception": {
"threw": "Exception",
"rowSurvived": true,
"verdict": "COMMITTED despite the exception"
},
"4-swallowed-exception": {
"rowSurvived": true,
"verdict": "COMMITTED -- the exception never reached the interceptor"
},
"5-called-from-post-construct": {
"transactionActiveDuringPostConstruct": false
},
"6-created-with-new": "created with new: actualTransactionActive=false"
}
Reading it:
0 control actualTransactionActive=true. The mechanism works.
1 self-invocation entryPoint() is not annotated and calls this.annotated...(),
so the proxy is never involved. Same class, same annotation,
no transaction.
2 private method a CGLIB proxy advises by overriding, and private methods
cannot be overridden. Legal Java, no effect.
3 checked exception the default rollback rule is RuntimeException or Error. A
checked exception propagates AND the transaction commits.
Fix: @Transactional(rollbackFor = Exception.class).
4 swallowed nothing propagates, so the interceptor sees a normal return
and commits. The write survives the failure it 'handled'.
5 @PostConstruct the proxy does not exist yet during initialisation.
6 new no container, no proxy, no transaction.
Note what rows 3 and 4 have in common: the row is still there afterwards. These two
do not merely fail to start a transaction -- they start one and COMMIT work that the
code was trying to abandon.