Why MyBatis‑Plus’s saveBatch Triggers Unexpected Transaction Rollbacks and How to Fix It

In a Java Spring project the author encountered the error message

Transaction rolled back because it has been marked as rollback-only

during testing of a feature. The message indicates that a transaction was marked for rollback, typically due to an inner transaction failure while the outer transaction still attempts to commit.

The root cause is often nested transactions: the inner service method throws an exception, is caught, and marks the current transaction as rollback‑only. When the outer service later tries to commit, the transaction manager detects the rollback flag and throws the above error.

The author provides a simplified example where a service method annotated with @Transactional calls another service method also annotated with @Transactional. If the inner call fails, the outer transaction ends up with a rollback‑only flag, leading to the observed exception.

While investigating, the author discovered that MyBatis‑Plus’s saveBatch method internally adds a @Transactional annotation. This hidden annotation effectively creates a nested transaction even though the developer did not intend to use one.

Because the hidden transaction propagates with the default propagation (REQUIRED), the inner transaction’s rollback flag propagates to the outer transaction, reproducing the error when duplicate keys are present. The outer try‑catch block swallows the exception, so the failure only becomes visible at commit time.

Two obvious fixes are not feasible: removing the @Transactional annotation from saveBatch (it is part of the library source) or changing its propagation to REQUIRES_NEW or NESTED (also not configurable).

The practical solution is to avoid using MyBatis‑Plus’s saveBatch in this scenario and implement a custom batch insert via a mapper, thereby controlling the transaction boundaries explicitly.

After replacing saveBatch with a manual batch insert, the author redeployed the service, confirmed that the error no longer occurs, and concluded that third‑party code can introduce hidden transaction behavior that requires careful review.

Key takeaways: always verify the transactional semantics of third‑party utilities, especially batch operations, and be prepared to replace them with custom implementations when they interfere with your transaction design.

@Override
@Transactional(rollbackFor = Exception.class)
public Boolean xxx(xxx dto) {
    list1 = ...;
    try {
        // batch save list1 to DB
    } catch (Exception e) {
        if (e instanceof DuplicateKeyException) {
            // filter duplicate keys and save filtered list1
        }
        // other handling
    }
    sendToMQ(xxx);
    list2 = ...;
    try {
        // batch save list2 to DB
    } catch (Exception e) {
        if (e instanceof DuplicateKeyException) {
            // filter duplicate keys and save filtered list2
        }
        // other handling
    }
    sendToMQ(xxx);
    return Boolean.TRUE;
}