当一个 @Transactional 方法（使用事务管理器 tmA）调用另一个标注了不同事务管理器（tmB）的 @Transactional 方法时，由于事务管理器隔离，将启动独立的新事务，而非沿用外层事务——二者互不嵌套、各自提交，需特别注意数据一致性风险。
当一个 `@transactional` 方法（使用事务管理器 tma）调用另一个标注了不同事务管理器（tmb）的 `@transactional` 方法时，由于事务管理器隔离，将**启动独立的新事务**，而非沿用外层事务——二者互不嵌套、各自提交，需特别注意数据一致性风险。
在 Spring 的声明式事务模型中，事务边界由 PlatformTransactionManager 实例严格界定。即使两个事务管理器（如 tmA 和 tmB）配置指向同一数据库、相同连接凭证，只要它们是不同的 Spring Bean 实例，Spring 就会将其视为完全独立的事务上下文。这意味着：事务传播行为（如 Propagation.REQUIRED）仅在同一事务管理器内生效；跨事务管理器调用时，传播规则“失效”，强制触发新事务。
以您提供的代码为例：
class A {
private B b;
@Transactional(transactionManager = "tmA") // 使用 tmA 管理事务
public void a() {
b.b(); // 同步调用 —— 注意：非代理调用！
}
}
class B {
@Transactional(transactionManager = "tmB") // 使用 tmB 管理事务
public void b() {
// 执行 DB 操作（如 insert into table_b）
}
}
⚠️ 关键前提：b.b() 必须是通过 Spring 代理的调用（即 b 是由 Spring 容器注入的代理对象），否则 @Transactional 在 b() 上根本不会生效。若 b 是 this 内部直接调用或手动 new B()，则事务注解被完全忽略。
✅ 正确执行流程如下（OSIV 已禁用，无额外 Session 干扰）：
-
a()被调用 →tmA启动事务 T1； -
b.b()经代理触发 →tmB无视 T1 存在，启动全新事务 T2； -
b()内所有数据库操作在 T2 中执行，T2 提交/回滚独立于 T1； -
b()返回后，控制权回到a()，T1 继续运行； -
a()正常结束 → T1 提交。
因此，不存在“事务延续”或“嵌套事务”（Spring 默认不支持真正的嵌套事务，NESTED 仅对单个 DataSourceTransactionManager 有效）。两个事务彼此透明，既不共享隔离级别，也不共享回滚状态——若 b() 抛出未捕获异常导致 T2 回滚，T1 仍可能成功提交，造成数据不一致。
? 实际建议：
- ✅ 若业务逻辑强耦合（如需原子性保障），应统一使用同一个事务管理器，并通过合理的服务分层或
@Transactional合并来管理边界； - ⚠️ 若必须多数据源（如跨库），且需强一致性，请改用分布式事务方案（如 Seata、XA 或 Saga 模式），而非依赖多个本地事务管理器；
- ? 避免为“同一物理库不同 schema”人为配置多个
DataSource+ 多个TransactionManager——这徒增复杂度且无实际收益； - ? 可通过
TransactionSynchronizationManager在运行时验证当前事务资源：System.out.println("Active tx for tmA: " + TransactionSynchronizationManager.isActualTransactionActive()); // 但注意：它仅反映当前线程绑定的 *默认* 事务资源，不感知其他 tm
总之，Spring 的事务管理以 PlatformTransactionManager 为单位进行隔离。不同事务管理器 = 不同事务宇宙。理解这一点，是设计可靠事务边界的起点。
