spring的事务传播机制
背景：实习期间几次遇到事务方法，有一次本地测试时发现事务没有回滚，就把简单描述写在wx上，今天来给spring事务做个自我总结。
1、why
为什么会有事务传播机制？
场景一：
- serviceA 方法调用了 serviceB 方法，但两个方法都有事务，这个时候如果 serviceB 方法异常，是让 serviceB 方法提交，还是两个一起回滚。
场景二：
- serviceA 方法调用了 serviceB 方法，但是只有 serviceA 方法加了事务，是否把 serviceB 也加入 serviceA 的事务，如果 serviceB 异常，是否回滚 serviceA 。
场景三：
- serviceA 方法调用了 serviceB 方法，两者都有事务，serviceB 已经正常执行完，但 serviceA 异常，是否需要回滚 serviceB 的数据。
所以，我们需要有对应的事务传播机制来控制事务。
2、传播机制生效的条件
有了spring事务传播机制，那这种机制存在的条件呢？我们知道，spring的事务是基于aop的，确切来说，是基于JDK动态代理的AOP，这种AOP有什么特点呢？ 它是基于类或者接口的，也就是说，当 @Transactional写在一个方法上时，这个方法将会被spring动态代理， 生成一个动态代理类， 对原方法进行修饰增强，但是要注意！！ 原先的方法的类并没有什么不同，并没有事务，spring动态代理这个类生成的代理类才有事务，才有增强，也就是说，在同一个类里面通过this.xx()调用本类的事务方法时，事务是不会生效的，因为你调用的不是代理类。
|
1
2
3
4
5
6
7
8
9
10
|
@Transactional
@Override
public void method1() {
this.method2();
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
@Override
public void method2() {
xx
}
|
解决方案
关键在于获取类的代理对象，而不是通过this去调用，所以以下方法都是基于这个关键点去解决的。
- 1、最简单的，两个事务方法放在不同的service里面，这个比较简单，就不给例子了。（推荐）
- 2、AOP上下文。spring提供了AOP上下文AopContext，因此通过AopContext，可以很方便的获取到代理对象。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
public class Myservice{
@Transactional
@Override
public void method1() {
((Myservice)AopContext.currentProxy()).method2();
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
@Override
public void method2() {
xx
}
}
|
一运行，报错了，因为exposeProxy默认为false，我们要暴露代理类，就要设置为true，可以在springboot启动类上加一个注解
|
1
|
@EnableAspectJAutoProxy(exposeProxy = true)
|
- 3、ApplicationContext
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
public class Myservice{
@Autowired
ApplicationContext context;
Myservice service;
@PostConstruct //初始化时调用，不加也行
private void getMyservice() {
service = context.getBean(Myservice.class);
}
@Transactional
@Override
public void method1() {
service.method2();
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
@Override
public void method2() {
xx
}
}
|
第二和第三种的区别就在于，2是直接获取代理类，3是通过调用getBean间接获取代理类，总的来说，第一种是最方便的，也是最推荐的做法。
3、传播机制类型
下面的类型都是针对于被调用方法来说的，理解起来要想象成两个 service 方法的调用才可以。
PROPAGATION_REQUIRED (默认)
- 支持当前事务，如果当前没有事务，则新建事务
- 如果当前存在事务，则加入当前事务，合并成一个事务
REQUIRES_NEW （一般用在子方法需要单独事务）
- 新建事务，如果当前存在事务，则把当前事务挂起
- 这个方法会独立提交事务，不受调用者的事务影响，父级异常，它也是正常提交
- （上面两个类型是常用的，下面的比较少用）
NESTED
- 如果当前存在事务，它将会成为父级事务的一个子事务，方法结束后并没有提交，只有等父事务结束才提交
- 如果当前没有事务，则新建事务
- 如果它异常，父级可以捕获它的异常而不进行回滚，正常提交
- 但如果父级异常，它必然回滚，这就是和 REQUIRES_NEW 的区别
SUPPORTS
- 如果当前存在事务，则加入事务
- 如果当前不存在事务，则以非事务方式运行，这个和不写没区别
NOT_SUPPORTED
- 以非事务方式运行
- 如果当前存在事务，则把当前事务挂起
MANDATORY
- 如果当前存在事务，则运行在当前事务中
- 如果当前无事务，则抛出异常，也即父级方法必须有事务
NEVER
- 以非事务方式运行，如果当前存在事务，则抛出异常，即父级方法必须无事务
以上为个人经验，希望能给大家一个参考，也希望大家多多支持服务器之家。
原文链接：https://blog.csdn.net/weixin_40378837/article/details/104715157