Spring事务传播与嵌套回滚详解

Spring事务中，Propagation.REQUIRED在嵌套调用时因复用同一事务对象，内层异常会将整个事务标记为rollback-only，导致外层即使捕获异常并继续执行，最终仍抛出UnexpectedRollbackException——这不是Bug，而是传播机制的必然结果；要实现“内层失败、外层照常提交”，必须改用REQUIRES_NEW（新建独立物理事务，完全隔离）或NESTED（基于保存点的嵌套回滚，依赖数据库InnoDB等支持），同时务必显式配置rollbackFor=Exception.class并确认数据源与数据库引擎兼容性，否则再正确的传播设置也形同虚设。

默认的 Propagation.REQUIRED 在嵌套调用中无法隔离异常影响，外层事务捕获内层异常后会抛出 UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only —— 这不是 bug，而是传播机制的必然结果。

为什么 Propagation.REQUIRED 嵌套调用会触发 rollback-only 异常

Spring 事务是基于 AOP 代理 + 线程绑定 TransactionStatus 实现的。当内层方法（如 serviceB.b()）被 @Transactional(propagation = Propagation.REQUIRED) 修饰，且当前已有外层事务时，它直接复用同一事务对象。

一旦内层方法抛出未被捕获的异常（比如 RuntimeException），Spring 的 completeTransactionAfterThrowing 会调用 rollback()，并将该事务状态标记为 rollback-only。此时外层方法若用 try-catch 吞掉异常并继续执行，等外层方法正常结束时，Spring 发现事务已是 rollback-only 却要 commit()，就强制抛出 UnexpectedRollbackException。

• 关键点：事务对象是共享的，rollback-only 是写在同一个 TransactionStatus 实例上的布尔标记
• 常见误判：以为“catch 了异常就等于事务没受影响”，实际事务状态早已不可逆地被污染
• 典型错误代码：serviceA.a() 调用 serviceB.b()，b() 抛 RuntimeException，a() 中 catch 后继续执行 insert 操作

想让内层失败、外层仍能提交，必须换传播行为

只有 Propagation.REQUIRES_NEW 或 Propagation.NESTED 能打破事务共享，但二者语义和兼容性完全不同：

• Propagation.REQUIRES_NEW：完全新建物理事务，挂起外层事务；内层回滚不影响外层，外层回滚也不影响内层已提交的数据；要求数据库支持事务挂起（如 MySQL 5.7+、PostgreSQL 都支持）
• Propagation.NESTED：不新建事务，而是在当前事务内设 savepoint；内层失败仅回滚到 savepoint，外层仍可提交；依赖数据库 savepoint 支持（MySQL InnoDB 支持，MyISAM 不支持）
• Propagation.SUPPORTS / Propagation.NOT_SUPPORTED 等不开启事务，无法控制内层回滚，排除

示例（推荐 REQUIRES_NEW 场景）：

@Service
public class ServiceA {
    @Resource private ServiceB serviceB;

    @Transactional
    public void a() {
        // 外层事务：插入用户
        userMapper.insert(...);

        try {
            serviceB.b(); // 内层独立事务
        } catch (Exception e) {
            // 忽略，不影响外层
        }

        // 外层继续执行并提交
        logMapper.info("user created");
    }
}

@Service
public class ServiceB {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void b() {
        // 即使这里抛 RuntimeException，只回滚本事务
        orderMapper.create(...);
        throw new RuntimeException();
    }
}

别忽略 rollbackFor 和数据库引擎限制

传播行为只是第一步，两个硬性条件不满足，任何传播设置都无效：

• @Transactional(rollbackFor = Exception.class) 必须显式声明：Spring 默认只对 RuntimeException 和 Error 回滚，Exception 及其子类（如 IOException）不会触发回滚，即使传播行为正确
• Propagation.NESTED 要求 JDBC 驱动开启 savepoint 支持（Spring 默认开启，但需确认 DataSource 未禁用），且底层数据库引擎必须支持（MySQL 的 MyISAM 表不支持 savepoint，InnoDB 才行）
• Propagation.REQUIRES_NEW 在某些连接池（如 HikariCP）中可能因连接复用导致事务隔离失效，建议配合 isolation = Isolation.DEFAULT 使用，避免手动指定隔离级别干扰挂起逻辑

最易被忽略的调试线索：日志里看事务是否真的“新”了

当怀疑传播行为没生效时，不要只查代码注解，直接看 Spring 事务日志（开启 org.springframework.transaction DEBUG 级别）：

• 出现 Creating new transaction → REQUIRES_NEW 生效
• 出现 Participating in existing transaction → 还是 REQUIRED，检查是否加在 private 方法、this 调用或非代理对象上
• 出现 Setting savepoint for nested transaction → NESTED 生效，否则可能是数据库不支持或 JDBC 配置问题

真实项目里，REQUIRES_NEW 更可控；NESTED 看似轻量，但 savepoint 的回滚粒度、与数据库锁的交互、以及部分 ORM 框架（如 MyBatis）对 savepoint 的兼容性，都比表面复杂得多。

终于介绍完啦！小伙伴们，这篇关于《Spring事务传播与嵌套回滚详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！