Spring 事务的传播机制

Spring 在 TransactionDefinition 接口中规定了 7 种类型的事务传播行为:

---

PROPAGATION_REQUIRED – 支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。

PROPAGATION_SUPPORTS – 支持当前事务，如果当前没有事务，就以非事务方式执行。

PROPAGATION_MANDATORY – 支持当前事务，如果当前没有事务，就抛出异常。

---

PROPAGATION_REQUIRES_NEW – 新建事务，如果当前存在事务，把当前事务挂起。

PROPAGATION_NOT_SUPPORTED – 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。

PROPAGATION_NEVER – 以非事务方式执行，如果当前存在事务，则抛出异常。

---

PROPAGATION_NESTED – 如果当前存在事务，则在嵌套事务内执行。

---

这里主要解释一下 REQUIRES_NEW 和 NESTED 的区别：

PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 “内部” 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行.

PROPAGATION_NESTED 开始一个 “嵌套的” 事务, 它是已经存在事务的一个真正的子事务. 潜套事务开始执行时, 它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交.

ServiceA {        
    void methodA() {          //methodA 为外部方法
        ServiceB.methodB();   //methodB 为内部方法
    }  

}  

ServiceB {   
    void methodB() {  
    }      
}     

如果ServiceA#methodA的事务属性为REQUIRED, ServiceB#methodB 的事务属性为 REQUIRES_NEW, 那么两者不会发生任何关系, ServiceA#methodA 和 ServiceB#methodB 不会因为对方的执行情况而影响事务的结果, 因为它们根本就是两个事务, 在 ServiceB#methodB 执行时 ServiceA#methodA 的事务已经挂起了

如果ServiceA#methodA的事务属性为REQUIRED, ServiceB#methodB 的事务属性为 NESTED，那么ServiceB#methodB 如果 rollback, 那么内部事务(即 ServiceB#methodB) 将回滚到它执行前的 SavePoint， 而外部事务(即 ServiceA#methodA) 可以有以下两种处理方式:

1. 改写 ServiceA 如下

ServiceA {  

    /** 
     * 事务属性配置为 PROPAGATION_REQUIRED 
     */  
    void methodA() {  
        try {  
            ServiceB.methodB();  
        } catch (SomeException) {  
            // 执行其他业务, 如 ServiceC.methodC();  
        }  
    }  

}  

这种方式也是潜套事务最有价值的地方, 它起到了分支执行的效果, 如果 ServiceB.methodB 失败, 那么执行 ServiceC.methodC(), 而 ServiceB.methodB 已经回滚到它执行之前的 SavePoint, 所以不会产生脏数据(相当于此方法从未执行过), 这种特性可以用在某些特殊的业务中, 而 PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRES_NEW 都没有办法做到这一点

2.代码不做任何修改, 那么如果内部事务(即 ServiceB#methodB) rollback, 那么首先 ServiceB.methodB 回滚到它执行之前的 SavePoint(在任何情况下都会如此), 外部事务(即 ServiceA#methodA) 将根据具体的配置决定自己是 commit 还是 rollback