In enterprise Java development, the @Transactional annotation is widely used to manage database transactions. However, developers often encounter situations where the transaction does not roll back as expected. This article explores the fundamental concepts of transactions and lists the most common scenarios that cause Spring-managed transactions to fail.

Understanding Transaction Fundamentals

A transaction is the smallest unit of logic that acts as a single indivisible operation. It adheres to the ACID principles:

• Atomicity: All operations within the transaction succeed or fail together. For example, if Account A transfers $100 to Account B, A must lose $100 and B must gain $100 simultaneously.
• Consistency: The system moves from one valid state to another. The total sum of money before and after the transfer remains the same.
• Isolation: Concurrent transactions do not interfere with each other.
• Durability: Once committed, changes are permanent, even in the event of a system failure.

Base Setup for Testing

We will use a standard Spring Boot environment with the following stack:

• Java 8
• Maven
• Docker (for MySQL)
• Spring Boot / Spring Data

Validating Correct Rollback Behavior

First, let's define a service that updates user records. We intentionally cause an error after the first udpate to verify the rollback.

@Service
public class AccountService {

    @Autowired
    private AccountRepository accountRepo;

    @Transactional
    public void incrementAges() {
        // Update user with ID 1
        accountRepo.increaseAge(1);
        
        // Simulate an exception
        int calculation = 10 / 0;
        
        // Update user with ID 2 (This should not happen if rollback works)
        accountRepo.increaseAge(2);
    }
}

If the transaction works, the age of user 1 remains unchanged after the ArithmeticException. However, several factors can break this behavior.

1. Incorrect Database Engine

MySQL supports multiple storage engines. Only InnoDB supports transactions. If your table uses MyISAM, the @Transactional annotation will be ignored.

Check your table engine:

SHOW TABLE STATUS WHERE Name = 'account';

If the engine is MyISAM, alter it:

ALTER TABLE account ENGINE=InnoDB;

2. Method Visibility Restrictions

Spring uses Proxy-based AOP to manage transactions. Due to the nature of Java proxies, @Transactional only works on public methods.

• Private: Not proxied, transaction ignored.
• Final: Cannot be overridden by the proxy, transaction ignored.
• Protected: Generally not recommended; may not be intercepted depending on the proxy mechanism (JDK vs CGLIB).

3. Exception Type Handling

By default, Spring rolls back transactions only for unchecked exceptions (RuntimeException and its subclasses) and Errors.

If you catch an exception and throw a checked exception (like IOException or SQLException), the transaction will not roll back automatically.

@Transactional
public void processData() throws IOException {
    accountRepo.increaseAge(1);
    try {
        int x = 1 / 0;
    } catch (Exception e) {
        // Throwing a checked exception here prevents default rollback
        throw new IOException("File error");
    }
}

4. Configuration Issues

• Multiple DataSources: Ensure you are using the correct PlatformTransactionManager for the specific database you are updating.
• Spring Boot Auto-configuration: Spring Boot automatically enables transaction management via TransactionAutoConfiguration. You usually do not need @EnableTransactionManagement unless you have a custom setup.
• Class vs. Method: Placing @Transactional on a class makes all public methods transactional.

5. Internal Method Calls (Self-Invocation)

A common pitfall is calling a transactional method from another method within the same class. Because the call happens inside the object rather than through the proxy, the transaction interceptor is never triggered.

@Service
public class AccountService {

    public void performUpdate() {
        // This calls the method directly on 'this', bypassing the proxy
        this.internalUpdate(); 
    }

    @Transactional
    public void internalUpdate() {
        accountRepo.increaseAge(1);
        int x = 1 / 0; // No rollback will happen here
    }
}

Solution: Separate the transactional logic into a different Spring Bean and inject it.

6. Multi-threading Context

Transactions are bound to a specific thread (using ThreadLocal). If you start a new thread inside a transactional method, that new thread will not share the transaction context.

@Transactional
public void asyncUpdate() {
    new Thread(() -> {
        // This runs in a new thread, creates a new SqlSession, 
        // and is NOT part of the outer transaction.
        accountRepo.increaseAge(1);
    }).start();

    int x = 1 / 0; // Rolls back only the main thread's work
}

7. Transaction Propagation and Nesting

When one transactional method calls another, the behavior depends on the Propagation setting. The default is Propagation.REQUIRED, meaning the inner method joins the outer transaction.

The "Rollback-Only" Trap: If an inner method throws an exception, the entire transaction is marked as "rollback-only". If the outer method catches this exception and tries to continue or commit, Spring throws:

org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only

To handle this, you can either re-throw the runtime exception or manually mark the status:

import org.springframework.transaction.interceptor.TransactionAspectSupport;

@Transactional
public void outerMethod() {
    try {
        innerMethod();
    } catch (Exception e) {
        // Manually mark for rollback if you catch the exception
        TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
    }
}

8. External Network Calls

Transactional databases only guarantee rollback for database operations. If your method calls an external API (e.g., a payment gateway) and then rolls back the local DB transaction, the external API call is not undone.

This leads to data inconsistency (e.g., the payment was made, but your local order status reverted). Ensure the external system supports idempotency or compensating transactions (Saga pattern) to handle such failures.