SpringBoot 事务回滚迷局：层层调用，事务边界如何界定？

从现在开始，努力学习吧！本文《SpringBoot 事务回滚迷局：层层调用，事务边界如何界定？》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

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 事务回滚迷局：层层调用，事务边界如何界定？》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！