5 Common Spring Transaction Pitfalls and How to Fix Them

Hello everyone, I’m your friend Architect Jun, a code‑writing architect.

Late one night an ops colleague called about a payment that succeeded but the order status never updated. I discovered the refund service’s updateOrderStatus() method was annotated with @Transactional, yet the database rollback didn’t happen and the order remained in the "Paid" state. This is a classic transaction‑failure pitfall caused by internal method calls within the same service class.

Scenario 1: Internal method calls in the same class disable the transaction

Problem: A public void refund() method in OrderService calls updateOrderStatus() (which has @Transactional), but the transaction is ineffective.

Reason: Spring transactions work through proxy objects; a self‑call bypasses the proxy, so no transaction is applied.

Solution:

Move the called method to another bean, e.g., OrderStatusService.

Use AopContext.currentProxy() to invoke the proxy (enable with @EnableAspectJAutoProxy(exposeProxy = true)).

((OrderService) AopContext.currentProxy()).updateOrderStatus();

Scenario 2: Non‑public methods are never transactional

Problem: Adding @Transactional to a private void updateInventory() method does not roll back inventory changes.

Truth: Spring only creates proxies for public methods; protected, default, and private methods are ignored.

Solution:

Annotate only public methods.

If internal calls are needed, apply the proxy technique from Scenario 1.

Scenario 3: Swallowed exceptions prevent rollback

Problem: Wrapping transactional code in a try‑catch block and not re‑throwing the exception causes Spring to commit even when an error occurs.

Mechanism: Spring rolls back only on unchecked (RuntimeException) by default; catching and suppressing the exception makes the transaction think everything succeeded.

Solution:

After catching, re‑throw a RuntimeException (e.g., throw new RuntimeException(e)).

Or configure @Transactional(rollbackFor = Exception.class) to roll back for all exceptions.

@Transactional
public void transfer() {
    try {
        withdraw(); // debit
        deposit();  // credit
    } catch (Exception e) {
        log.error("Transfer failed", e);
        throw new RuntimeException(e);
    }
}

Scenario 4: final/static methods cannot be proxied

Problem: Adding @Transactional to a public final void pay() or a static void encryptCard() method has no effect.

Reason: Final and static methods cannot be overridden by proxies, so transaction code is never injected.

Solution:

Avoid using final or static on transactional methods.

Extract the core logic to a regular bean and let the transactional method call it.

Scenario 5: MySQL storage engine incompatibility

Problem: Using the MyISAM engine, which does not support transactions, makes all transactional operations ineffective.

Check: Run SHOW TABLE STATUS LIKE 'order_table'; and ensure the Engine column shows InnoDB.

Fix:

Create new tables with ENGINE=InnoDB.

Convert existing tables:

ALTER TABLE order_table ENGINE=InnoDB;

Self‑check table (for interview)

Same‑class call → partial rollback → split bean or use AopContext.

Non‑public method → no rollback → annotate only public methods.

Exception swallowed → commit → re‑throw or use rollbackFor.

final/static method → proxy fails → avoid final/static in transactional code.

MyISAM engine → all transactions fail → switch to InnoDB.

Three iron rules for reliable transactions

Annotate only public methods with @Transactional.

When a method in the same class needs a transaction, call it through a proxy or move it to another bean.

Never swallow exceptions; either re‑throw or configure rollbackFor for checked exceptions.

Next time an interviewer asks “Have you encountered transaction failures?”, mention these details to impress.