Common Spring Transaction Failure Scenarios and Their Solutions

In real projects, developers often rely on Spring transaction mechanisms to maintain data consistency across multiple tables, but many encounter transaction failure scenarios that are hard to diagnose.

The article lists the most common causes:

Methods annotated with @Transactional are not public.

The class containing @Transactional is not a Spring‑managed bean.

The transactional method is invoked internally within the same class.

The business code throws a checked exception instead of a RuntimeException.

An exception is caught without rethrowing, preventing rollback.

Incorrect propagation setting, e.g., Propagation.NOT_SUPPORTED.

Using MySQL with the MyISAM engine, which does not support transactions.

Non‑public method : Spring proxies only apply transactional behavior to public methods. The official documentation states that protected, private, or package‑visible methods will not trigger transaction settings. The solution is to keep @Transactional on public methods or enable AspectJ weaving.

Bean not managed by Spring :

public class StudentServiceImpl implements StudentService {

@Autowired private StudentMapper studentMapper;

@Transactional

public void insertClassByException(StudentDo studentDo) throws CustomException {

studentMapper.insertStudent(studentDo);

throw new CustomException();

}

If the class lacks @Service (or another stereotype), Spring will not create a proxy, and the transaction will never be applied.

Internal method call : When method b() annotated with @Transactional is called from method a() within the same class, the call bypasses the proxy, so the transaction is not started. Example:

public void insertClass(ClassDo classDo) throws CustomException {

insertClassByException(classDo); // no transaction

}

@Transactional

public void insertClassByException(ClassDo classDo) throws CustomException {

classMapper.insertClass(classDo);

throw new RuntimeException();

}

Test results show the database insert succeeds despite the exception. The fix is to invoke the method via the proxy:

((ClassServiceImpl) AopContext.currentProxy()).insertClassByException(classDo);

Also ensure @EnableAspectJAutoProxy(exposeProxy = true) is added to the configuration.

Checked exception : By default, Spring rolls back only on unchecked exceptions. Throwing a checked Exception will not trigger rollback. Adding rollbackFor = Exception.class to the annotation solves the issue:

@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)

Catching without rethrow : Wrapping transactional code in a try‑catch block and swallowing the exception prevents rollback. The solution is to rethrow a RuntimeException after handling:

try { int i = 1/0; } catch (Exception e) { e.printStackTrace(); throw new RuntimeException(); }

Wrong propagation : Using Propagation.NOT_SUPPORTED disables transaction support for the method.

MySQL storage engine : If the table uses the MyISAM engine, transactions are not supported; switch to InnoDB to enable transactional behavior.