当应用连接多个数据库时，需配置多个 transactionmanager；@transactional 默认传播级别 required 并不会跨管理器“合并”事务，不同事务管理器始终独立开启和管理各自事务，无法自动协调回滚。
当应用连接多个数据库时，需配置多个 transactionmanager；@transactional 默认传播级别 required 并不会跨管理器“合并”事务，不同事务管理器始终独立开启和管理各自事务，无法自动协调回滚。
在 Spring 中，@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 回滚其事务（仅影响子库）；
- 二者完全独立，无原子性保证：主库已提交而子库回滚，或反之，均可能发生 —— 这属于典型的分布式事务不一致场景。
✅ 正确解法：使用 ChainedTransactionManager（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");
}? 重要注意事项：
- ChainedTransactionManager 的回滚是逆序执行（先 subTxm.rollback()，再 mainTxm.rollback()），确保资源释放顺序合理；
- 若中间某管理器提交失败（如网络中断），后续管理器的 commit() 将跳过，但已提交的上游事务无法自动回滚（这是其局限性，本质仍是尽力而为型）；
- 生产环境涉及资金、订单等强一致性要求时，应优先考虑 Seata、Atomikos（JTA）或 Saga 模式，而非 ChainedTransactionManager；
- 所有 DAO 操作必须在同一个 @Transactional 方法内完成（即避免跨 Bean 的事务传播歧义），否则链式管理器无法生效。
总结：Spring 的 @Transactional 天然不支持跨事务管理器的事务传播。多数据源事务一致性不能依赖 REQUIRED 的“加入”语义，而需显式选用协调机制——ChainedTransactionManager 是轻量可行的入门方案，但务必理解其边界与风险。
