其实，

上篇文章讲了同一个类里方法调方法不走代理导致 @Transactional 不生效——这是“代理绕过”的问题。这篇我们更进一步：就算走了代理、@Transactional 正常触发了它到底管了多少？

你以为 @Transactional 会管所有数据源？它只管理了一个 JD娱乐 Connection 的 begin/commit/rollback。同一个 DataSource 上开的新 Connection 它也不管。不是配置错了——是 Annotation 本身的设计边界。

三年前接到的那个工单，让我第一次把这个边界看清楚。

—— 一个“管不到”的案例

使用者痛点：下单失败、钱已扣却订单未生成，投诉激增。程序响应时间从 200ms 飙升至 0.2s，日志全是 Connection is not available,request timed out。

第一反应是连接池不够，但 HikariCP 监控显示：

active: 。max: 

所有连接都被占满，没有释放。

业务 QPS 本应只需要 个连接，为何实际吃掉了 个？进一步排查日志发现：

-- :: INFO o.x.ServiceA - outer: order_id=ORD20260627001 created
-- :: INFO o.x.ServiceB - inner: inventory locked for ORD20260627001
-- :: ERROR o.x.ServiceA - outer failed: payment timeout,rolling back...
-- :: INFO o.x.ServiceA - outer rolled back: order_id=ORD20260627001

订单回滚了库存锁仍在。外层方法标记了 @Transactional内层使用了 @Transactional。两个注解，一个回滚，一个提交。

痛点再现："有 @Transactional 罩着，怎么会只回滚一半？"

更大的痛点："成百上千的连接被挂起。却一直不归还池子"

—— @Transactional 的三层边界

Spring 声明式事务通过 AOP 拦截带有 @Transactional 的方法，并在内部自动管理 JD娱乐 Connection 的事务生命周期。说起来，下面分三层来解释它到底能管什么、不能管什么。

第一层的观点是，JD娱乐 边界 —— @Transactional = Connection 管理

TransactionInterceptor 拦截后委托 DataSourceTransactionManager 执行实际事务操作。其实，说到其主要实现是，

// TransactionInterceptor -> DataSourceTransactionManager.doBegin
Connection con = dataSource.getConnection;con.setAutoCommit;// 此后@Transactional 管理的仅是该 Connection 的 begin / commit / rollback

关键细节：

• TransactionSynchronizationManager 保存一个映射：
• {@link DataSourceTransactionManager#doGetTransaction} 检查当前线程是否已经绑定了该 DataSource 的 ConnectionHolder
• If exists → reuse；else → 从连接池获取新 Connection 并绑定到线程。

A 与 B 两个服务的调用过程示意：

ServiceA.createOrder # @Transactional
-> doBegin on Connection_A
-> ServiceB.lockInventory # @Transactional
-> 挂起 Connection_A
-> 从池子拿 Connection_B
-> doBegin on Connection_B
-> commit
-> 恢复 Connection_A
-> outer rollback

Pain point："同一次请求出现两个物理连接。外层回滚并未影响内层已提交的数据"

再看第二层，传播边界 —— REQUIRES_NEW 开新连接

P​ropagation.REQUIRES_NEW 的实现逻辑如下：

• Suspend 当前线程绑定的 Connection
• 从数据源 获取全新的 Connection

This explains *** “外层回滚不影响内层”。因为它们根本使用的是不同的物理数据库连接。

说到第三层，数据源边界 —— 不同 DataSource 更管不到

If you have multiple DataSources,each typically has its own DataSourceTransactionManager. When you omit @Transactional。Spring picks one marked @Primary. Any operation using a non‑primary DataSource will be completely invisible to chosen transaction manager.

This is *** many multi‑DB projects encounter “半改” bugs when only one DB is wrapped by a transaction.

—— 理解边界后的正确选择

The problem isn’t a bug in Spring;不过，it’s an assumption that annotation can magically manage *all* connections. Once you know its limits。pick right tool for each scenario.

三条铁的规则

• #1 多数据源必须显式指定 transactionManager。

// ❌ 错误：未指定，默认取 @Primary。
只管主库
@Transactional
public void createOrderAndDeduct {…}
// ✅ 正确：显式指定链式事务管理器，统一跨库提交/回滚
@Transactional
public void createOrderAndDeduct { …}

// 链式管理器配置
@Configuration
public class ChainedTxConfig {
@Bean
public PlatformTransactionManager chainedTxManager(
@Qualifier PlatformTransactionManager orderTx,@Qualifier PlatformTransactionManager accountTx) {
return new ChainedTransactionManager;}
}

• #2 REQUIRES_NEW 必须确认“外层回滚时内层是否需要一起回滚”。
• If inner data must be rolled back toger → 使用 REQUIRED，让其加入外部事务。
• If inner data can stay committed → 保持 REQUIRES_NEW。但要做好补偿机制，并评估对连接池的额外压力。
• Sizing tip： `maxPoolSize = 并发数 × ` 才能避免 “Connection 被挂起不归还”。​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​  )
• #3 在 REQUIRED 传播下隐式使用 @Primary 常常埋下跨库失效坑。

// 多数据源项目中，每次写 @Transactional 前都要问：
// “这个注解到底管理的是哪个 DataSource？”
// 不加参数默认使用 @Primary，可能不是业务想要的那个。@Transactional
public void foo{ …}

如何验证当前 @Transactional 管了哪些连接

You can use Arthas to inspect thread‑local resources stored in TransactionSynchronizationManager.resources.

vmtool --action getInstances \
--className org.springframework.transaction.support.TransactionSynchronizationManager \
--express 'instances.{resources.get.toString}' -x

动手验证这方面，最小复现 Demo 


@SpringBootTest
class TransactionBoundaryTest {
@Autowired private JdbcTemplate jdbc;@Autowired private PlatformTransactionManager txMgr;@Test
void testRequiresNewUsesSeparateConnection {
// 外层事务
TransactionStatus outer = txMgr.getTransaction);jdbc.execute");// 内层 REQUIRES_NEW
DefaultTransactionDefinition def = new DefaultTransactionDefinition;def.setPropagationBehavior;TransactionStatus inner = txMgr.getTransaction;jdbc.execute");txMgr.commit;// inner 提交
txMgr.rollback;按理说，// outer 回滚
// 验证结果：表中仅剩 'inner' 一条记录。'outer' 已被撤销。}


}


—— 🔴 在你的项目里搜这些 🚩 



@Transactional without specifying a transaction manager or value. 检查所有此类方法，确认它们只涉及单一 DataSource；否则会出现“只管到一半”的情况。

P­ropagation.REQUIRES_NEW. 如果外层可能回滚。请核实内层已提交的数据是否已有补偿措施，否则会产生“库存扣减却订单撤销”的典型使用者痛点。话说回来，

@DataSourceTransactionManager beans. 统计项目中有多少个实例。它们各自对应哪个 DataSource；确保每个业务方法都显式指向合适的 manager，而不是默认的 @Primary。

使用 Arthas 或自定义拦截器打印 ThreadLocal 中绑定的资源，以快速定位隐藏的多连线场景。.






"