SpringBoot 事务回滚迷局：层层调用，事务边界如何界定？
从现在开始，努力学习吧！本文《SpringBoot 事务回滚迷局：层层调用，事务边界如何界定？》主要讲解了等等相关知识点，我会在中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！
springboot 事务回滚谜团：层层调用的事务边界
考虑以下代码场景：
方法 A 调用 B，B 调用 C，C 调用 D，D 调用 E。A、C、D 和 E 均位于同一类中，但只有 B 标记了事务。
此时，即使 e 方法出错，事务也不会回滚。原因何在？
深入事务边界
在 springboot 中，事务是由 @transactional 注解控制的。当在某个方法上应用此注解时，它便开启了一个事务范围。当出现异常时，如果该方法处于事务范围内，则该事务将回滚，所做的更改将被撤销。
事务的传播性
然而，当方法调用嵌套事务时，事务的传播性就变得至关重要。有两种主要传播性级别：
- required：如果存在父事务，则加入该事务；否则，开启一个新事务。
- not_supported：暂停当前事务，在非事务性环境中执行方法。
springboot 的事务默认传播性
默认情况下，springboot 使用 required 传播性级别。这意味着只有当最外层方法标记了事务时，整个方法调用链中的事务才会被触发。
本案例的解释
在给定场景中，由于只有 b 方法标记了事务，因此 a、c、d 和 e 方法都在非事务性环境中执行。当 e 方法出错时，由于没有父事务，事务不会回滚。
解决方法
要想让事务对整个方法调用链起作用，有两种解决方案：
- 为最外层方法 a 添加 @transactional 注解，以覆盖默认的传播性。
- 更改 b 方法的事务传播性为 not_supported，以便嵌套方法能够在自己的事务中运行。
终于介绍完啦！小伙伴们，这篇关于《SpringBoot 事务回滚迷局：层层调用，事务边界如何界定？》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~公众号也会发布文章相关知识，快来关注吧！
