浅谈spring的嵌套事务

逃离我推掉我的手 2024-03-22 09:17 40阅读 0赞

### 1.当我们在谈论嵌套事务的时候，嵌套的是什么？ ###

当看到\`嵌套事务\`第一反应想到是这样式的：

![format_png][]

但这更像`PROPAGATION_REQUIRES_NEW`啊，感兴趣可以去打断点执行一下。`PROPAGATION_REQUIRES_NEW`事务传播下，方法A调用方法B就是这样，

//        事务A doBegin()
    //            事务B doBegin()
    //            事务B doCommit()
    //        事务A doCommit()
     
    复制代码

而在`PROPAGATION_NESTED`事务传播下，打了个断点，会发现只会执行一次doBegin和doCommit：

事务A doBegin()
    事务A doCommit()
    复制代码

我们用代码输出更加直观。  
定义两个方法serviceA和serviceB,使用前者调用后者。前者事务传播使用`REQUIRED`,后者使用`PROPAGATION_NESTED`。

@Transactional(propagation = Propagation.REQUIRED)
        public void serviceA(){
                Tcity tcity2 = new Tcity();
                tcity2.setId(0);
                tcity2.setStateCode("5");
                tcity2.setCnCity("测试城市2");
                tcity2.setCountryCode("ALB");
                tcityMapper.insertSelective(tcity2);
                transactionInfo();
                test2.serviceB();
        }
    复制代码

@Transactional(rollbackFor = Exception.class, propagation = Propagation.NESTED)
        public void serviceB() {
            Tcity tcity = new Tcity();
            tcity.setId(0);
            tcity.setStateCode("5");
            tcity.setCnCity("测试城市");
            tcity.setCountryCode("ALB");
            tcityMapper.insertSelective(tcity);
            tcityMapper.selectAll2();
            transactionInfo();
    复制代码

这里的transactionInfo()使用事务同步器管理器`TransactionSynchronizationManager`注册一个事务同步器`TransactionSynchronization`。  
这样在事务完成之后`afterCompletion`会输出当前事务是`commit`还是`rollback`，这样也便于测试，比起去刷新数据库看有没有写入，更加方便快捷直观。

同时使用`TransactionSynchronizationManager.getCurrentTransactionName()`可以得到当前事务的名称，这样可以直观的看到当前方法使用的是同一个事务还是不同的事务。

protected void transactionInfo() {
    
            String transactionName = TransactionSynchronizationManager.getCurrentTransactionName();
            boolean active = TransactionSynchronizationManager.isActualTransactionActive();
            log.info("transactionName:{}, active:{}", transactionName, active);
    
            if (!active) {
                log.info("transaction ：{} not active", transactionName);
                return;
            }
            TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
                @Override
                public void afterCompletion(int status) {
                    if (status == STATUS_COMMITTED) {
                        log.info("transaction ：{} commit", transactionName);
                    } else if (status == STATUS_ROLLED_BACK) {
                        log.info("transaction ：{} rollback", transactionName);
                    } else {
                        log.info("transaction ：{}  unknown", transactionName);
                    }
                }
            });
        }
    复制代码

执行测试代码：

@RunWith(SpringRunner.class)
    @SpringBootTest
    public class Test { 
        @Autowired
        private Test1 test1;
    
        @org.junit.Test
        public void test(){
            test1.serviceA();
        }
    }
    复制代码

输出：

![format_png 1][]

可以非常直观地观察到3点情况： 1.通过上图标记为1的地方，可以看到两个方法使用了一个事务`com.nyp.test.service.propagation.Test1.serviceA`。  
2.通过上图标记为2的地方，以及箭头顺序，可以看到事务执行顺序类似于（事实上不是，只是事务同步器的问题，下文有说明）：

//        事务A doBegin()
    //            事务B doBegin()
    //        事务A doCommit()
    //            事务B doCommit()
    复制代码

3.通过事务同步器打印日志发现commit执行了两次。

以上2，3两点与前面打断点的结论貌似是有点冲突。

#### 1.1嵌套事务究竟有几个事务 ####

源码版本:spring-tx 5.3.25

通过源码，可以很直观地观察到，`useSavepointForNestedTransaction()`默认返回true,这样就不会开启一个新的事务(`startTransaction`), 而是创建一个新的`savepoint`。

![format_png 2][]

相当于在方法A的时候会开启一个新的事务，在调用方法B的时候，会在方法A之后方法B之前创建一个检查点。

类似于在原来的A方法上手动添加检查点。

@Transactional(propagation = Propagation.REQUIRED)
        public void serviceA(){
            Object savePoint = null;
            try {
                Tcity tcity2 = new Tcity();
                tcity2.setId(0);
                tcity2.setStateCode("5");
                tcity2.setCnCity("测试城市2");
                tcity2.setCountryCode("ALB");
                tcityMapper.insertSelective(tcity2);
                transactionInfo();
                savePoint = TransactionAspectSupport.currentTransactionStatus().createSavepoint();
                test2.serviceB();
            } catch (Exception exception) {
                exception.printStackTrace();
                TransactionAspectSupport.currentTransactionStatus().rollbackToSavepoint(savePoint);
            }
        }
    复制代码

然后通过检查点，将一个`逻辑事务`分为多个`物理事务`。  
我这可不是在乱讲啊，我是有备而来。

[github.com/spring-proj…][github.com_spring-proj]  
上面是spring 在github官方社区07年的一个贴子，`Juergen Hoeller`有一段回复。

`Juergen Hoeller`是谁？他是spring的联合创始人，事务这一块的主要开发者。

![format_png 3][]

> PROPAGATION\_NESTED的不同之处在于，它使用具有多个保存点的单个物理事务，可以回滚到这些保存点。这种部分回滚允许内部事务范围触发其范围的回滚，而外部事务可以继续进行物理事务，尽管已经回滚了一些操作。这通常映射到JDBC保存点上，因此只适用于JDBC资源事务(Spring的DataSourceTransactionManager)。

在嵌套事务中，整体是一个逻辑事务，通过savepoint在jdbc物理层面把调用方法分割成一个个的物理事务。  
因为spring层面只有一个逻辑事务，所以通过断点只执行了一次doBegin()和doCommit()，但实际上执行了两次preCommit()，如果有savepoint那就不执行commit(),  
这也能回答上面2，3两点问题的疑问。

![format_png 4][]

所以上面方法A调用方法B进行嵌套事务，右图比左图更形象准确：

![format_png 5][]

#### 1.2 savepoint ####

savepoint是JDBC的一种机制，spring运用savepoint来实现了嵌套事务。  
在数据库操作中，默认autocommit为true，意味着一条SQL一个事务。也可以将autocommit设置为false，将多条SQL组成一个事务，一起commit或者rollback。  
以上都是常规操作，在一个事务中所以数据库操作全部捆绑在一起。在某些特定情况下，在一个事务中，用户只希望rollback其中某部份，这时候可以用到savepoint。

记我们忘掉`@Transactional`，以编程式事务的方式来手动设置一个savepoint。

方法A，写入一条用户记录，并设置一个检查点。

@Autowired
        private PlatformTransactionManager platformTransactionManager;
    
        public void serviceA(){
            TransactionStatus status = platformTransactionManager.getTransaction(new DefaultTransactionDefinition());
            Object savePoint = null;
            try {
                Person person = new Person();
                person.setName("张三");
                personDao.insertSelective(person);
                transactionInfo();
                // 设置一个savepoint
                savePoint = status.createSavepoint();
                test2.serviceB();
            } catch (Exception exception) {
                exception.printStackTrace();
                // 这里输出两次commit,到rollback到51行,会插入一条数据
                status.rollbackToSavepoint(savePoint);
                // 这里会两次rollback
    //            platformTransactionManager.rollback(status);
    
            }
            platformTransactionManager.commit(status);
        }
    复制代码

方法B写入一条日志记录。并在此模拟一个异常。

public void serviceB() {
            TLog tLog = new TLog();
            tLog.setOprate("user");
            transactionInfo();
            tLogDao.insertSelective(tLog);     
            int a = 1 / 0;
        }
    复制代码

测试希望达到的效果是，日志写入失败，但用户记录写入成功。很明显，如果不使用savepoint是达不到的。因为两个方法是一个事务，在方法B中报错了，抛出异常，用户和日志的数据库操作都将回滚。

测试输出日志：

[2023-04-24 14:40:18.740] INFO 88384 [main] [com.nyp.test.service.propagation.Test1] : transactionName:null, active:true
    [2023-04-24 14:40:18.742] INFO 88384 [main] [com.nyp.test.service.propagation.Test2] : transactionName:null, active:true
    java.lang.ArithmeticException: / by zero
    	......省略
    [2023-04-24 14:40:18.747] INFO 88384 [main] [com.nyp.test.service.propagation.Test1] : transaction ：null commit
    [2023-04-24 14:40:18.747] INFO 88384 [main] [com.nyp.test.service.propagation.Test2] : transaction ：null commit
    
    复制代码

数据库也表明用户写入成功，日志写入失败。

![format_png 6][]

### 2.一开始的问题，B先回滚A再正常提交？ ###

本文开始的问题是方法A事务传播为`PROPAGATION_REQUIRED`，方法B事务传播为`PROPAGATION_NESTED`。方法A调用B，methodA正常，methodB抛异常。  
这种情况下会发生什么？

`B先回滚，A再正常提交`这种说法为什么会有问题，有什么问题？

#### 2.1 先B后A的顺序有问题吗？ ####

通过前面事务同步器打印的日志我们得知，事务以`test1.serviceA()执行doBegin(),test2.serviceB()执行doBegin(),test1.serviceA()执行doCommit(),test2.serviceB()执行doCommit()`这样的顺序执行。

![format_png 7][]

但是果真如此吗？

通过源码我们首先得知，preCommit()在commit()方法之前，在preCommit()会做savepoint的判断，如果有检查点就不执行commit()。

1.  同时方法B只是一个savepoint不是一个真正的事务，并不会执行事务同步器。
    
    ![format_png 8][]
2.  方法A是一个真正的事务，所以会执行commit(),同时也会执行上面的事务同步器。

![format_png 9][]

这里的事务同步器是一个Arraylist,它的执行顺序即是arraylist的遍历顺序，仅仅只代表加入的先后，并不代表事务真正commit/rollback的顺序。

从1，2两点可以得出结论，先B后A的顺序并没有问题。

同时，根据1，在嵌套事务中使用事务同步器要特别小心，在检查点的时候并不会执行同步器，同时会掩盖真正的操作。

比如方法B回滚了，但因为方法B只是个savepoint，所以事务同步器不会执行。等到方法A执行完操作事务同步器的时候，也只会反应外层事务即方法A的事务结果。

#### 2.2 真正的问题 ####

如果B回滚，A是commit还是rollback取决于方法A是否继续把异常往上抛。

让我们先暂时忘掉嵌套事务，测试一个REQUIRES\_NEW的案例。  
同样的方法A事务传播为`REQUIRES`，方法B为`REQUIRES_NEW`。 此时方法A和方法B为两个彼此独立的事务。 方法A调用方法B，方法B抛出异常。  
此时，方法B肯定会回滚，但方法A呢？按理说彼此独立，那肯定是commit了。  
  
但真的如此吗？  
(1). 方法A不做异常处理。

测试结果：

![format_png 10][]

可以看到确实是两个事务，但两个事务都rollback了。因为方法A虽然没有报异常，但它接到了方法B的异常且往上抛了，spring只会认为方法A同样也抛出了异常。因此两个事务都需要回滚。

(2).方法A处理了异常。

将方法A代码try-catch住，再执行。

日志有点多不做截图，

[2023-04-24 16:10:30.669] INFO 96664 [main] [com.nyp.test.service.propagation.Test1] : transactionName:com.nyp.test.service.propagation.Test1.serviceA, active:true
    [2023-04-24 16:10:30.672] INFO 96664 [main] [com.nyp.test.service.propagation.Test2] : transactionName:com.nyp.test.service.propagation.Test2.serviceB, active:true
    [2023-04-24 16:10:30.687] INFO 96664 [main] [com.nyp.test.service.propagation.Test2] : transaction ：com.nyp.test.service.propagation.Test2.serviceB rollback
    java.lang.ArithmeticException: / by zero
    	 省略
    [2023-04-24 16:10:30.689] INFO 96664 [main] [com.nyp.test.service.propagation.Test1] : transaction ：com.nyp.test.service.propagation.Test1.serviceA commit
    复制代码

可以看到两个单独的事务，事务B回滚了，事务A提交了。

虽然我们这小节说的是`REQUIRES_NEW`，但嵌套事务是一样的道理。

`如果B回滚，当方法A继续往上抛异常，则A回滚；当方法A处理了异常不往上抛，则A提交。`

### 3. 场景 ###

在2.2小节中，我们举了`REQUIRES_NEW`的例子来说明，有的同学可能就会有点疑问了。既然事务B回滚了，事务A都要根据情况来判断是否回滚，那这样嵌套事务跟`REQUIRES_NEW`有啥区别？

还是拿注册的场景来说。往数据库写1条用户记录，再写1条注册成功操作日志。

1.  如果日志写入失败，用户写入不受影响。这种情况下， `REQUIRES_NEW`和嵌套事务都能实现。而且很明显`REQUIRES_NEW`还没那么弯弯绕绕。 2.考虑另外一种情况，如果用户写入失败了，那这时候我想要日志写入也失败。因为用户都没了，就不存在注册操作成功的操作日志了。

这种场景，在方法B为`REQUIRES_NEW`模式下，打印输出

![format_png 11][]

可以看到方法B提交了，也就是说用户注册失败了，但用户注册成功的操作日志却写入成功了。

我们再来看看嵌套事务的情况下： 方法A传播级别为REQUIRED,并模拟一个异常。

@Transactional(propagation = Propagation.REQUIRED)
        public void serviceA(){
            Person person = new Person();
            person.setName("李四");
            personDao.insertSelective(person);
            transactionInfo();
            test2.serviceB();
            int a = 1 / 0;
        }
    复制代码

方法B事务传播级别为NESTED。

@Transactional(propagation = Propagation.NESTED)
        public void serviceB() {
            TLog tLog = new TLog();
            tLog.setOprate("user");
            transactionInfo();
            tLogDao.insertSelective(tLog);
        }
    
    复制代码

执行日志

![format_png 12][]

可以看到同一个逻辑事务下的两段物理事务都回滚了，达到了我们预期的效果。

### 4.小结 ###

1.方法A事务传播为REQUIRED，方法B事务传播为NESTED。方法A调用方法B，当B抛出异常时，  
如果A处理了异常，此时事务A提交。否则，事务A回滚。

2.REQUIRED\_NEW和NESTED在有些场景下可以实现相同的功能，但在某些特定场景下只能NESTED实现。  
3.NESTED底层逻辑是JDBC的savepoint。父事务类似于一个逻辑事务，savepoint将各方法分割了若干物理事务。  
4.在嵌套事务中使用事务同步器时需要特别小心。

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/5484ac55f785471b838d79dcc659374b.png
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/1360728578904a49ba63814c9fe656e9.png
[format_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/2e661b174414496da19b0bd7232abe75.png
[github.com_spring-proj]: https://github.com/spring-projects/spring-framework/issues/8135
[format_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/12aa5f98eb29439fbb06639bed512094.png
[format_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/26979710751548748f33f0f67b23bf33.png
[format_png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/362e7710356f4aa39a015001fab65c83.png
[format_png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/c0abf1103095459ca07ddcb695110ffa.png
[format_png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/db0bfa7b735f419e9467338f7afce6a2.png
[format_png 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/42d1c11357be46b9bcd99fc5571131cf.png
[format_png 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/16109433aa6443e68c1547e0132798a9.png
[format_png 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/5f90e0730a5846ad8bfc89c44dc5b341.png
[format_png 11]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/553d0101cb4b4273b29664946935d5a1.png
[format_png 12]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/9712e1d1fcb2492c81f729024e4d0967.png