Common Scenarios Where Spring Transactions Fail and How to Fix Them

Spring's @Transactional annotation is convenient for managing database transactions, but it can silently fail in many common situations, leading to data inconsistency.

1. Method visibility: only public methods are proxied; private, protected or package‑private methods will not trigger a transaction.

@Service
public class UserService {
    @Transactional
    private void add(UserModel user) { 
        // ...
    }
}

2. Final methods: Spring cannot create a subclass proxy for final methods, so the transaction is ignored.

@Service
public class UserService {
    @Transactional
    public final void add(UserModel user) { 
        // ...
    }
}

3. Self‑invocation: calling another @Transactional method from the same class uses the original object (this) and bypasses the proxy, causing the inner method to run without a transaction.

public void save(User user) {
    // direct call – no transaction
    updateStatus(user);
}

Solutions include extracting the called method to another @Service, injecting the current bean, or using AopContext.currentProxy() to obtain the proxy.

4. Bean not managed by Spring: forgetting @Service/@Component means the class is not a Spring bean, so @Transactional has no effect.

5. Multithreading: transactions are bound to the thread; spawning a new thread breaks the transaction context.

6. Non‑transactional tables: engines such as MyISAM do not support transactions, so even a correctly configured method cannot roll back.

7. Transaction not enabled: missing DataSourceTransactionManager configuration or incorrect pointcut expressions prevent transaction creation.

8. Rollback rules: using the wrong propagation attribute, catching exceptions, or specifying an inappropriate rollbackFor can stop rollback.

9. Nested transactions: with Propagation.NESTED an exception that propagates out will roll back the whole outer transaction unless it is caught locally.

10. Large transactions: annotating a whole method may include many read‑only queries, increasing lock time; consider moving only the necessary statements into a dedicated transactional block or use programmatic TransactionTemplate for finer control.

Overall, understanding these pitfalls and applying the suggested fixes helps ensure Spring transactions work reliably.