spring 事务传播机制总结

为什么会有传播机制

spring 对事务的控制，是使用 aop 切面实现的，我们不用关心事务的开始，提交 ，回滚，只需要在方法上加 @Transactional 注解，这时候就有问题了。

场景一： serviceA 方法调用了 serviceB 方法，但两个方法都有事务，这个时候如果 serviceB 方法异常，是让 serviceB 方法提交，还是两个一起回滚。
场景二：serviceA 方法调用了 serviceB 方法，但是只有 serviceA 方法加了事务，是否把 serviceB 也加入 serviceA 的事务，如果 serviceB 异常，是否回滚 serviceA 。
场景三：serviceA 方法调用了 serviceB 方法，两者都有事务，serviceB 已经正常执行完，但 serviceA 异常，是否需要回滚 serviceB 的数据。

传播机制生效条件

因为 spring 是使用 aop 来代理事务控制 ，是针对于接口或类的，所以在同一个 service 类中两个方法的调用，传播机制是不生效的

传播机制类型

下面的类型都是针对于被调用方法来说的，理解起来要想象成两个 service 方法的调用才可以。

注解配置时如：@Transactional(propagation=Propagation.REQUIRED)

示例代码

ServiceA
 
ServiceA {   
     void methodA() {
         ServiceB.methodB();
     }
}
ServiceB
 
ServiceB { 
     void methodB() {
     }      
}

PROPAGATION_REQUIRED / REQUIRED (默认)

支持当前事务，如果当前没有事务，则新建事务

如果当前存在事务，则加入当前事务，合并成一个事务

如果上下文中已经存在事务，那么就加入到事务中执行，如果当前上下文中不存在事务，则新建事务执行。所以这个级别通常能满足处理大多数的业务场景。

子事务回滚，父事务一定回滚

父事务回滚，子事务一定回滚

假如当前正要运行的事务不在另外一个事务里，那么就起一个新的事务 比方说，ServiceB.methodB的事务级别定义PROPAGATION_REQUIRED, 那么因为执行ServiceA.methodA的时候，ServiceA.methodA已经起了事务。这时调用ServiceB.methodB，ServiceB.methodB看到自己已经执行在ServiceA.methodA的事务内部。就不再起新的事务。而假如ServiceA.methodA执行的时候发现自己没有在事务中，他就会为自己分配一个事务。这样，在ServiceA.methodA或者在ServiceB.methodB内的不论什么地方出现异常。事务都会被回滚。即使ServiceB.methodB的事务已经被提交，可是ServiceA.methodA在接下来fail要回滚，ServiceB.methodB也要回滚

REQUIRES_NEW

新建事务，如果当前存在事务，则把当前事务挂起

这个方法会独立提交事务，不受调用者的事务影响，父级异常，它也是正常提交

如果不起作用，可能的原因如下：调用方与被调用方写在了同一个service类里面，需要用Spring的上下文获取对象。
例如：((ABCServiceImpl) SpringContextHolder.getBean(“注册的标识符”))

这个就比较绕口了。 比方我们设计ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_REQUIRES_NEW。那么当运行到ServiceB.methodB的时候，ServiceA.methodA所在的事务就会挂起。ServiceB.methodB会起一个新的事务。等待ServiceB.methodB的事务完毕以后，他才继续运行。
他与PROPAGATION_REQUIRED 的事务差别在于事务的回滚程度了。由于ServiceB.methodB是新起一个事务，那么就是存在两个不同的事务。假设ServiceB.methodB已经提交，那么ServiceA.methodA失败回滚。ServiceB.methodB是不会回滚的。假设ServiceB.methodB失败回滚，假设他抛出的异常被ServiceA.methodA捕获，ServiceA.methodA事务仍然可能提交。

NESTED

如果当前存在事务，它将会成为父级事务的一个子事务，方法结束后并没有提交，只有等父事务结束才提交
如果当前没有事务，则新建事务
如果它异常，父级可以捕获它的异常而不进行回滚，正常提交
但如果父级异常，它必然回滚，这就是和 REQUIRES_NEW 的区别

SUPPORTS

如果当前存在事务，则加入事务
如果当前不存在事务，则以非事务方式运行，这个和不写没区别

NOT_SUPPORTED

以非事务方式运行
如果当前存在事务，则把当前事务挂起

MANDATORY

如果当前存在事务，则运行在当前事务中
如果当前无事务，则抛出异常，也即父级方法必须有事务

NEVER

以非事务方式运行，如果当前存在事务，则抛出异常，即父级方法必须无事务

一点小说明

一般用得比较多的是 PROPAGATION_REQUIRED ， REQUIRES_NEW；

REQUIRES_NEW 一般用在子方法需要单独事务，暂时找不到例子，以后补充 。

小总结

四种隔离级别

注解配置时如：@Transactional(isolation = Isolation.READ_UNCOMMITTED)

事务隔离级别	脏读	不可重复读	幻读
读未提交(Read-Uncommitted)	是	是	是
不可重复读(Read-Committed)	否	是	是
可重复读(Repeatable-Read)	否	否	是
串行化(Serializable)	否	否	否

其中：可重复读(repeatable-read)表示：在开始读取数据（事务开启）时，不再允许修改操作

mysql默认的事务隔离级别为repeatable-read

事务的并发问题

1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据

2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。

3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表

转载自https://blog.csdn.net/xushiyu1996818/article/details/107000161