Debugging Spring @Transactional Rollback: A Hands‑On Source Code Guide

In this tutorial I show how to read Spring source code to understand the rollback behavior of @Transactional annotations.

Build the Demo

First create a simple three‑layer project with a Controller , a Service and a local database.

The Student entity maps two fields for demonstration.

With this tiny demo you can start debugging in ten minutes.

Methodology: Focus on Call Stack

Debugging is essentially placing breakpoints and stepping through code.

Place the first breakpoint at the entry of the transactional method.

When the program stops, the IDE shows a call‑stack view, which displays the chain of method calls ending at the current breakpoint.

In our demo the stack contains:

① TestController method – program entry.

② String AOP related method.

③ Transaction‑related logic.

④ The current breakpoint.

Focus on the transaction part (③) to answer the rollback question.

org.springframework.transaction.interceptor.TransactionInterceptor#invoke

This is the real first breakpoint where the framework decides whether to roll back.

Methodology: Watch the Logs

Set the root logging level to debug and run the demo. logging.level.root=debug The console will show many lines; the transaction start and commit are logged.

Acquired Connection [HikariProxyConnection@... wrapping com.mysql.cj.jdbc.ConnectionImpl@...] for JDBC transaction<br/>Switching JDBC Connection ... to manual commit<br/>...<br/>==>  Preparing: insert into student (name, home) values (?, ?)<br/>...<br/>Committing JDBC transaction on Connection [HikariProxyConnection@...]<br/>Releasing JDBC Connection [HikariProxyConnection@...] after transaction

Search the log text to locate the source line that produces it.

org.springframework.jdbc.datasource.DataSourceTransactionManager.doBegin:263 - Acquired Connection [...] for JDBC transaction

Place a breakpoint here, restart, and run the request again to get a new call stack.

Methodology: Find Callers of the Target Method

Search where @Transactional is used and examine the few call sites.

Most call sites are in tests; the real business code shows the rollbackFor and noRollbackFor attributes.

Exploring the Answer

Debug the method TransactionInterceptor#invoke and follow the flow to completeTransactionAfterThrowing (rollback) or commitTransactionAfterReturning (commit).

The crucial logic resides in RuleBasedTransactionAttribute#rollbackOn.

org.springframework.transaction.interceptor.RuleBasedTransactionAttribute#rollbackOn

It iterates over rollbackRules, matches the thrown exception against rollbackFor and noRollbackFor, and selects a winner. If the winner is a NoRollbackRuleAttribute, the method returns false (no rollback); otherwise it returns true.

The winner is the rule whose exception type is closest (in inheritance distance) to the actual exception.

Examples:

When a RuntimeException is thrown and noRollbackFor=RuntimeException.class, the distance is 0, so no rollback.

When a NullPointerException is thrown with rollbackFor=RuntimeException.class, the distance to RuntimeException is 1, which is shorter than the distance to Exception, so rollback occurs.

Adjusting the logging level to trace can reveal which rule wins.

logging.level.root=trace

By following these steps you can reliably locate the first effective breakpoint for any Spring feature, such as @Cacheable or @Async, and build your own methodology.