Common Pitfalls of Spring Transaction Management and How to Avoid Them

Spring supports both declarative and programmatic transaction management, with most developers using the declarative @Transactional annotation. Because transactions are implemented via AOP proxies (JDK dynamic proxies or CGLIB), several pitfalls can cause transactions to become ineffective or degrade performance.

Proxy‑related pitfalls : By default, Spring creates a JDK dynamic proxy if the target class implements an interface; otherwise it uses CGLIB. Certain methods cannot be proxied, leading to transaction failure. The relevant class can be inspected in org.springframework.aop.framework.DefaultAopProxyFactory .

Method visibility issues :

Adding @Transactional to a final method does not work.

Static methods annotated with @Transactional are ignored.

Non‑public methods will not trigger transaction management.

These problems can be avoided by using class‑based (CGLIB) proxies or switching to AspectJ weaving.

Self‑invocation : When a method within the same class calls another @Transactional method, the call bypasses the proxy, so the transaction does not start.

Exception handling pitfalls :

Only unchecked exceptions (RuntimeException, Error) trigger rollback by default; checked exceptions (Exception) do not.

To roll back on checked exceptions, specify @Transactional(rollbackFor = Exception.class) .

The rollback logic is implemented in org.springframework.transaction.interceptor.TransactionAspectSupport#completeTransactionAfterThrowing and org.springframework.transaction.interceptor.RuleBasedTransactionAttribute#rollbackOn .

Propagation and nested transactions : The default propagation is Propagation.REQUIRED . To run a sub‑transaction independently, use Propagation.REQUIRES_NEW .

Exception swallowing : Catching exceptions inside a transactional method without re‑throwing prevents Spring from detecting the failure, so the transaction will not roll back.

Asynchronous execution : Transaction context is stored in ThreadLocal; when execution moves to another thread, the transaction information is lost, causing no rollback.

Multiple data sources : A single local transaction must use one data source; mixing data sources requires a distributed transaction solution.

Bean not managed by Spring : If the class containing @Transactional is not a Spring bean, the annotation has no effect.

Missing transaction manager : Without a configured transaction manager, Spring cannot start or commit transactions.

AOP ordering : Spring’s transaction AOP has a default order defined in org.springframework.transaction.annotation.EnableTransactionManagement#order . Conflicting AOP order from other libraries can cause unexpected behavior.

Database‑related pitfalls :

Some database engines do not support transactions.

Large transactions can lock many rows, cause deadlocks, consume storage for rollback logs, and exhaust connection pools.

Long‑running transactions delay binlog writing, leading to replication lag.

How to avoid large transactions :

Do not indiscriminately annotate every method with @Transactional.

Split large transactions into smaller, independent ones.

Avoid distributed transactions when possible.

Process limited amounts of data per transaction.

Use transactions only when necessary.

By understanding these pitfalls and applying the suggested mitigations, developers can ensure that Spring transaction management works reliably in real‑world applications.