当一个 @Transactional 方法调用另一个使用不同 transactionManager 的 @Transactional 方法时，由于事务管理器隔离，将触发独立的新事务，而非传播或挂起原有事务。OSIV 关闭时该行为确定且可预测。

当一个 `@transactional` 方法调用另一个使用不同 `transactionmanager` 的 `@transactional` 方法时，由于事务管理器隔离，将触发独立的新事务，而非传播或挂起原有事务。osiv 关闭时该行为确定且可预测。

在 Spring 的声明式事务模型中，@Transactional 的生效前提是代理机制正常介入（即通过 Spring 容器注入的 Bean 调用，而非 this 调用）。但更关键的是：事务管理器（PlatformTransactionManager）是事务边界的决定性因素之一。即使两个事务管理器指向同一数据库（相同 URL、用户名、密码），只要它们是不同的 Spring Bean 实例（如 tmA 和 tmB），Spring 就会将其视为完全独立的事务上下文。

事务不会传播，而是并行启动

以您提供的代码为例：

class A {
    private B b;
    @Transactional(transactionManager = "tmA") // 使用 tmA 管理事务
    public void a() {
        b.b(); // 通过代理调用，触发 B 的事务逻辑
    }
}

class B {
    @Transactional(transactionManager = "tmB") // 使用 tmB 管理事务
    public void b() { /* ... */ }
}

当 a() 被调用时：

• tmA 启动一个新事务（Propagation.REQUIRED，默认值）；
• 进入 b.b() 调用后，Spring 的事务拦截器检测到 @Transactional(transactionManager = "tmB")，立即查找并绑定 tmB 的事务上下文；
• 此时 tmB 当前无活跃事务 → 按 REQUIRED 规则启动一个全新事务，与 tmA 的事务完全无关；
• 两个事务各自提交（或回滚）：b() 返回后 tmB 事务提交；a() 结束后 tmA 事务提交。

⚠️ 注意：这不是嵌套事务（NESTED），也不是事务挂起（SUSPEND）——Spring 默认不支持跨事务管理器的挂起/恢复，因为每个 PlatformTransactionManager 维护自己独立的 TransactionSynchronizationManager 绑定线程变量（如 resources, synchronizations, currentTransactionName 等）。

验证行为的典型日志线索

启用 org.springframework.transaction 日志级别为 DEBUG，可观察到类似输出：

// 进入 a()
Creating new transaction with name [A.a]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
Opened new Session [SessionImpl...] for Hibernate transaction
...
// 进入 b() —— 注意 manager 切换
Creating new transaction with name [B.b]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT, transaction manager [tmB]
Opened new Session [SessionImpl...] for Hibernate transaction  // 新 Session！
...
// b() 提交
Initiating transaction commit
Committing Hibernate transaction on Session [SessionImpl...]
...
// a() 提交
Initiating transaction commit
Committing Hibernate transaction on Session [SessionImpl...] // 原 Session

关键注意事项与最佳实践

• ✅ 必须确保 b 是 Spring 管理的 Bean 并通过依赖注入调用：若在 A 中 new B() 或 this.b() 调用，@Transactional 将完全失效（代理未介入）。
• ⚠️ 不可依赖“同一数据库”实现事务一致性：tmA 和 tmB 的事务互不可见，b() 中的写操作对 a() 的后续查询不可见（除非已提交且隔离级别允许），也无法实现原子性回滚——一个失败，另一个仍可能提交。
• ? 避免在业务逻辑中混用多事务管理器：除非明确需要资源级隔离（如读写分离、分库分表、异构数据源），否则应统一事务管理器。若需多数据源事务一致性，请改用 JTA（如 Atomikos、Narayana）+ XA 数据源。
• ? 替代方案建议：
  • 若仅为逻辑分组，可移除 tmB，统一使用 tmA，并通过 @Transactional(propagation = Propagation.REQUIRES_NEW) 显式开启同一管理器下的新事务（此时支持挂起与恢复）；
  • 若确需双数据源协同，应在 service 层手动控制：先执行 tmA 事务，再执行 tmB 事务，并引入最终一致性补偿（Saga 模式）。

总之，在 Spring 中，事务管理器（transactionManager）是事务作用域的硬边界。跨管理器调用永远触发新事务，而非传播——这是设计使然，而非缺陷。理解这一点，是构建可靠分布式事务逻辑的前提。