Understanding @Transactional Rollback Behavior in Spring: When Exceptions Trigger Rollback

1. First I prepared a data row in MySQL

Insert a record where the delflag field is set to 0.

<update id="test">
    UPDATE tbl_users set delflag='0' where account='admin';
</update>

2. Simple test

Run a method annotated with @Transactional that deliberately causes a division‑by‑zero error, which throws java.lang.ArithmeticException (a subclass of RuntimeException).

@Override
@Transactional
public Ret test() {
    int i = articleMapper.test();
    int a = 2/0;
    if(i > 0){
        ResultUtil.success();
    }
    return ResultUtil.error();
}

The method aborts, the exception is caught by Spring, and the transaction is rolled back, leaving the database unchanged.

3. Checking the database

After the rollback the delflag remains unchanged, confirming that @Transactional rolled back for the RuntimeException.

4. Trying to roll back a checked exception

Replace the division‑by‑zero with a try‑catch that re‑throws a generic Exception. The transaction does not roll back, and the database value is updated to 0.

@Override
@Transactional
public Ret test() throws Exception {
    int i = articleMapper.test();
    try {
        int a = 2/0;
    } catch (Exception e) {
        throw new Exception();
    }
    if(i > 0){
        ResultUtil.success();
    }
    return ResultUtil.error();
}

This demonstrates that by default Spring only rolls back for RuntimeException and its subclasses.

5. How to roll back checked exceptions

Specify the exception class in the annotation, e.g. @Transactional(rollbackFor = Exception.class), to make the transaction roll back for checked exceptions as well.

Summary

@Transactional

rolls back for RuntimeException and its subclasses; it does not roll back for checked exceptions unless rollbackFor is configured.