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
3.2 KiB
← NESTED and JPA · Index · Isolation →
5. Six ways @Transactional silently does nothing
Sources: SilentlyNonTransactional,
NotABean.
Transcript: 04-silent-failures.txt.
Row 0 is the control: the same annotated method reached through the proxy reports
actualTransactionActive=true. The mechanism works. These six do not use it.
1. Self-invocation
public String entryPoint() {
return annotatedButCalledInternally(); // this. -> no proxy -> no transaction
}
@Transactional
public String annotatedButCalledInternally() { ... }
actualTransactionActive=false. The proxy wraps the object, not its methods; a call the
object makes to itself never leaves it.
Fix: move the method to another bean. Self-injection and AopContext.currentProxy() both
work and are both worse.
2. A private method
@Transactional on a private method is legal Java and inert: a CGLIB proxy advises by
overriding, and private methods cannot be overridden. IntelliJ warns; the compiler does not.
3. A checked exception commits
@Transactional
public void checkedExceptionCommits(String id) throws Exception {
accounts.save(new Account(id, 999));
throw new Exception("checked -- this does NOT trigger rollback");
}
"3-checked-exception": { "threw": "Exception", "rowSurvived": true,
"verdict": "COMMITTED despite the exception" }
The default rollback rule is RuntimeException or Error. A checked exception propagates to
the caller and the transaction commits on the way out.
Fix: @Transactional(rollbackFor = Exception.class).
4. Swallowing the exception
@Transactional
public void swallowsException(String id) {
accounts.save(new Account(id, 555));
try { throw new IllegalStateException("something went wrong"); }
catch (RuntimeException ex) { /* handled */ }
}
Nothing propagates, so the interceptor sees a normal return and commits. The write survives the failure the code appeared to handle.
Failures 3 and 4 are the dangerous pair: they do not merely fail to start a transaction, they commit work the code was trying to abandon.
5. Called from @PostConstruct
"5-called-from-post-construct": { "transactionActiveDuringPostConstruct": false }
The proxy does not exist while the bean is still initialising, so there is nothing to intercept the call. The reference documentation says not to rely on it; this measures what actually happens.
Fix: ApplicationReadyEvent or InitializingBean on a different bean.
6. An object created with new
No container, no proxy, no transaction. Survives code review easily because the annotation is right there on the method.
The one-line check
TransactionSynchronizationManager.isActualTransactionActive()
Drop it into the method you believe is transactional. If it prints false, you have one of
these six and no amount of reasoning about propagation will help.