大事务拆分项目应用-再看事务嵌套

事务嵌套详解与Spring事务传播属性

最新推荐文章于 2025-09-29 00:36:03 发布

原创

最新推荐文章于 2025-09-29 00:36:03 发布 · 3.2k 阅读

CC 4.0 BY-SA版权

文章标签：

本文探讨了事务嵌套的概念，特别是在支付系统中的应用场景，强调了事务嵌套对于保证数据一致性的必要性。同时，文章指出事务嵌套可能带来的问题，通过测试案例分析了事务回滚的情况。此外，简单介绍了Spring的事务传播属性，如REQUIRED、SUPPORTS、MANDATORY等，但未深入展开。

一、何为事务嵌套

最简单的事务嵌套情况：开启了一个事务的情况下，再开启一个事务2。

或者：在t1、t2分别为两个事务操作，而外层t3事务包含t1（t2），t3跟t1（t2）

例如在支付系统中，在进行支付校验时，事务1负责更新账单状态&插入历史表，事务2负责创建支付记录及明细，如果假设更新账单状态成功，二创建支付记录失败，则导致账单状态与支付状态丢失数据一致性。故除保证事务1、2的原子性外，还得在1、2上层增加事务3以保证两个事务组合也具有原子性。

二、事务嵌套有何问题？

思考一个问题：理论上，t1事务执行完毕后，如果t2执行失败，往上t3因为t2执行失败而回滚。此时t1能回滚成功么？talk is cheap ，show me the case！测试case如下。

case结果：

 
 1、session1中首先执行开始事务命令， start transaction;然后插入1条记录，查询session1中正常显示 

 
 2、在session2中查询该条记录，无匹配结果。 因为此时session1中未执行commit命令。mysql与oracle一样，未commit的数据除了当前session之外，其他session是看不到的。 

 
 3、直接开启第二个事务，即再一次执行