当一个 @Transactional 方法（使用事务管理器 tmA）调用另一个 @Transactional 方法（使用不同事务管理器 tmB）时，即使两者连接同一数据库，Spring 也会为后者启动独立事务——不会传播或复用前者的事务上下文。
当一个 `@transactional` 方法（使用事务管理器 tma）调用另一个 `@transactional` 方法（使用不同事务管理器 tmb）时，即使两者连接同一数据库，spring 也会为后者启动独立事务——不会传播或复用前者的事务上下文。
在 Spring 的事务管理机制中，事务管理器（PlatformTransactionManager）是事务边界的决定性因素。只要两个 @Transactional 方法指定了不同的 transactionManager 属性（如 "tmA" 和 "tmB"），无论它们是否操作同一数据库、甚至同一数据源，Spring 都会将它们视为完全隔离的事务域。
关键原理：事务管理器绑定事务上下文
Spring 的 TransactionSynchronizationManager 为每个线程维护一个 Map<object object></object>，其中 key 是 TransactionManager 实例（或其标识符），value 是该管理器对应的 TransactionStatus。这意味着：
-
tmA的事务状态与tmB的事务状态互不感知； -
Propagation.REQUIRED（默认行为）仅在「当前线程中、针对同一事务管理器」不存在活跃事务时才创建新事务； -
跨事务管理器调用不构成“已有事务”的上下文，因此
b()总会触发tmB的新事务，无论a()是否正在执行tmA事务。
示例行为还原
class A {
private B b;
@Transactional(transactionManager = "tmA") // ← 启动 tmA 事务
public void a() {
System.out.println("Before b() call: tmA transaction active = "
+ TransactionSynchronizationManager.isActualTransactionActive());
b.b(); // ← 触发 tmB 事务（全新生命周期）
System.out.println("After b() return: tmA still active = "
+ TransactionSynchronizationManager.isActualTransactionActive());
}
}
class B {
@Transactional(transactionManager = "tmB") // ← 独立启动 tmB 事务
public void b() {
// 此处运行在 tmB 的事务中
// tmA 的事务对它完全不可见
System.out.println("Inside b(): tmB transaction active = "
+ TransactionSynchronizationManager.isActualTransactionActive());
}
}输出示意：
Before b() call: tmA transaction active = true Inside b(): tmB transaction active = true After b() return: tmA still active = true
注意事项与实践建议
✅ 事务隔离性明确：tmA 和 tmB 的提交/回滚互不影响。若 b() 抛出未捕获异常导致 tmB 回滚，tmA 仍可正常提交（除非显式处理异常并传播）。
⚠️ 非原子性风险：这种设计天然不具备跨数据源（或跨管理器）的分布式事务能力。即使连接同一数据库，也无法保证 a() 和 b() 的操作在单个 ACID 事务中完成。
? 如需强一致性：应避免拆分事务管理器；统一使用一个 @Transactional（如 tmA），或将逻辑合并至同一服务类，由单一事务管理器统筹。
? 调试技巧：启用 logging.level.org.springframework.transaction=DEBUG 可清晰看到每个事务的 begin/commit/rollback 日志，并标注所属 transactionManager。
总之，Spring 的事务切面严格按 transactionManager 实例划分边界——不同管理器即不同事务世界。理解这一点，是规避“误以为事务传播生效”类问题的关键。
