Spring 中多事务管理器下 @Transactional 的行为解析

在Spring应用里连接多个数据库时，配置多个事务管理器是常见需求。这时候，一个关键问题就浮现出来了：@Transactional的默认传播级别REQUIRED，会不会聪明到自动跨不同的事务管理器，把操作合并成一个整体事务？答案是否定的。不同的事务管理器彼此之间，那是井水不犯河水，完全各管各的，根本没法自动协调回滚。

我们先捋清一个核心前提：@Transactional(transactionManager = "xxx")这个注解，明确指定了当前方法归属于哪个事务管理器，比如mainTransactionManager或subTransactionManager。关键点在于，事务管理器彼此隔离，互不感知。所谓的REQUIRED传播级别，它只做一件事——复用当前线程中由同一个事务管理器已经开启的事务。它绝不会将一个管理器的事务委托给另一个，也不会让不同管理器的事务互相加入或同步。这可不是什么设计缺陷，而是它的基本行为规则。

看一个具体例子，就全明白了：

@Transactional(transactionManager = "mainTransactionManager")
public class MainService {
    public void doMain() {
        mainDao.update(); // 在 mainTransactionManager 的事务中执行
        subService.doSub(result); // 调用另一类 —— 此时进入 SubService 方法
    }
}

@Transactional(transactionManager = "subTransactionManager")
public class SubService {
    public void doSub(String result) {
        subDao.update(result); // 在 subTransactionManager 的事务中执行（全新事务）
    }
}

这里要特别提醒一句：subService.doSub(...)虽然是在MainService的方法里被调用的，但因为它自己的@Transactional指向的是subTransactionManager，而当前线程中，压根不存在由这个管理器开启的活跃事务。所以，subTransactionManager会独立地启动一个全新的本地事务。这意味着什么？

• mainDao.update()执行失败 → mainTransactionManager回滚它自己的事务，只影响主库。
• subDao.update()执行失败 → subTransactionManager回滚它自己的事务，只影响子库。
• 关键是，两者完全独立，没有任何原子性保证。主库已经提交了，子库却回滚了，或者反过来——这一类典型的分布式事务不一致场景，随时可能发生。

那该怎么办呢？Spring Data Commons 提供了一个轻量级的方案：ChainedTransactionManager。

它的工作方式相当直接，是一种顺序式事务链管理器。你可以把它理解成一个调度员，把多个PlatformTransactionManager串成一个逻辑上的事务单元。它会按照你声明的顺序，依次调用每个管理器的doBegin()和doCommit()/doRollback()。达成一个“全成功才提交，任一失败就全部回滚”的近似强一致性效果。不过，必须说清楚，它和真正的两阶段提交（2PC）不是一回事，不提供跨库的隔离性与故障恢复能力。所以，它最适合用在多数同构数据库、低并发、非核心资金类的场景里。

配置起来很简洁：

@Bean
public PlatformTransactionManager chainedTransactionManager(
    @Qualifier("mainTransactionManager") PlatformTransactionManager mainTxm,
    @Qualifier("subTransactionManager") PlatformTransactionManager subTxm) {
    return new ChainedTransactionManager(mainTxm, subTxm);
}

然后，统一使用这个链式管理器：

@Transactional(transactionManager = "chainedTransactionManager")
public void doAtomicMultiDbOperation() {
    mainDao.update();
    subDao.update("Success");
}

使用中有几个关键点需要留意：

• 回滚顺序是逆序的：先执行subTxm.rollback()，再执行mainTxm.rollback()，这是为了保证资源释放的顺序是合理的。
• 存在“尽力而为”的局限：如果中间某个管理器提交失败（比如网络中断），后续的commit()会跳过，但已经提交成功的那几个上游事务，是无法自动回滚的。这是它固有的边界，本质上是尽力而为型方案。
• 适用场景要分清：在生产环境中，如果涉及资金、订单这类强一致性要求的业务，应该优先考虑 Seata、Atomikos（JTA）或 Saga 模式，而不是ChainedTransactionManager。
• 操作必须在同一方法内：所有 DAO 操作必须在同一个@Transactional方法内完成，避免跨 Bean 的事务传播歧义，否则链式管理器无法生效。

总结一下：Spring 的@Transactional天生就不支持跨事务管理器的事务传播。多数据源事务一致性，不能指望REQUIRED的“加入”语义来帮你自动协调。需要显式地引入一个协调机制——ChainedTransactionManager是一个轻量且容易上手的入门方案，但务必理解清楚它的边界和潜在风险，不要把它当成万能的银弹。