0


Spring事务传播机制

当我们在使用Spring所提供的事务功能时,如果是仅仅处理单个的事务,是比较容易把握事务的提交与回滚,不过一旦引入嵌套事务后,多个事务的回滚和提交就会变得复杂起来,各个事务之间是如何相互影响的,是一个值得讨论的点。

一、事务在Spring中是如何运作的

在了解嵌套事务之前,可以先看下单个事务在Spring中的处理流程,以便后面可以更清晰地认识嵌套事务的逻辑。

Spring事务使用AOP的机制实现,会在@Transactional注解修饰的方法前后分别织入开启事务的逻辑,以及提交或回滚的逻辑。@Transactional可以修饰在方法或者类上,区别就在于修饰于类上的,会对该类下符合条件的方法(例如private修饰的方法就不符合条件)前后都织入事务的逻辑。

具体的处理逻辑如下(具体的方法路径为TransactionInterceptor.invoke -> TransactionAspectSupport.invokeWithinTransaction):

1.1 开启事务(DataSourceTransactionManager.doBegin)

这里主要做了获取连接,并关闭自动提交,将@Transactional注解中的一些参数初始化到txObject对象中。

1.2 异常回滚(TransactionAspectSupport.completeTransactionAfterThrowing)

这里是事务异常回滚的地方,这里有个注意点是回滚会先用rollbackOn这个方法判断,默认情况下只有RunTimeException以及Error是会进行回滚的,除非在@Transactional显式声明了rollbackFor。

二、Spring的事务传播机制

当出现多个事务嵌套的场景发生时,Spring事务的处理会变得复杂一些,需要考虑嵌套事务下的提交顺序,以及回滚顺序。对此,Spring提供了多种的传播机制,每种传播机制的效果都不尽相同,以便应对各种复杂的业务场景。

正常处理的嵌套事务流程如下:

传播机制以及它们的效果如下:

REQUIRED:默认值,支持当前事务,如果没有事务会创建一个新的事务

SUPPORTS:支持当前事务,如果没有事务的话以非事务方式执行

MANDATORY:支持当前事务,如果没有事务抛出异常

REQUIRES_NEW:创建一个新的事务并挂起当前事务

NOT_SUPPORTED:以非事务方式执行,如果当前存在事务则将当前事务挂起

NEVER:以非事务方式进行,如果存在事务则抛出异常

NESTED:如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则进行与REQUIRED类似的操作

以下的说明均建立在父事务的传播机制为REQUIRED的前提下,来探讨各种传播机制的回滚策略。

2.1 子事务的传播机制为REQUIRED

子事务

主事务

结果

异常

正常,并try-catch异常

均回滚

正常

异常

均回滚

正常

异常,并try-catch异常

不回滚

这里详细说下第一种场景,子事务异常情况下,主事务捕获了子事务的异常却仍发生了回滚。从代码来看:

回滚的原因在于,子事务失败的时候在回滚代码中设置了全局回滚的标识(AbstractPlatformTransactionManager.processRollback)。

之后主事务在进行事务提交时,会判断全局回滚标识是否存在。若存在就会进行回滚动作。(AbstractPlatformTransactionManager.commit)

2.2 子事务的传播机制为REQUIRES_NEW

子事务

主事务

结果

异常

正常,并try-catch异常

子回滚,主不回滚

正常

异常

子不回滚,主回滚

异常

正常

均回滚

这里主要说下第三种场景,因为从REQUIRES_NEW的描述中容易造成误解:创建一个新的事务并挂起当前事务,很容易理解为子事务独立于主事务,子事务回滚后不会影响主事务的执行。

我认为问题点主要在于对挂起的认识,可以看下Spring时如何执行的(AbstractPlatformTransactionManager.handleExistingTransaction):

在这个挂起动作中主要做了两件事,一是将全局ThreadLocal中的配置初始化,二是将原事务的信息保存在SuspendedResourcesHolder对象中。

当子事务异常回滚后,就会通过AbstractPlatformTransactionManager.resume方法恢复主事务。

恢复后,子会再向外抛出一个异常,因此主事务会接收到该异常,因此主事务也发生回滚。

总的来说,挂起的动作并不代表子完全独立于主。

2.3 子事务的传播机制为NESTED

子事务

主事务

结果

异常

正常,并try-catch异常

子回滚,主不回滚

正常

异常

均回滚

异常

正常

均回滚

NESTED是通过rollback的savepoint机制,实现异常回滚。相比于子事务为REQUIRED下,子事务异常,主事务try-catch了异常,REQUIRED情况下主子均会回滚,但NESTED模式主不会回滚。因此可以看下场景一,NESTED是如何处理的。

子事务如果是NESTED模式,则会保存savepoint,以便后面回滚到该savepoint。

回滚时,直接回滚到savepoint,且不会设置全局回滚标识。因此即相当于就是回滚了子事务。主事务由于try-catch了异常,因此执行方法的时候也没有抛出异常,正常走提交流程,且没有全局回滚标识,故不会回滚,正常提交。

**PS: **mysql的savepoint机制

BEGIN;

INSERT INTO test_entity values (1, 'aaa', 10); ①

SAVEPOINT savepoint1;

INSERT INTO test_entity values (2, 'bbb', 11); ②

ROLLBACK TO savepoint1;

RELEASE SAVEPOINT savepoint1;

COMMIT;

回滚到savepoint1,①会入库,②被回滚。

标签: spring java 后端

本文转载自: https://blog.csdn.net/szy350/article/details/122466050
版权归原作者 霂宇 所有, 如有侵权,请联系我们删除。

“Spring事务传播机制”的评论:

还没有评论