老生常谈spring的事务传播机制

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()调用本类的事务方法时,事务是不会生效的,因为你调用的不是代理类。

    @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,可以很方便的获取到代理对象。
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启动类上加一个注解

@EnableAspectJAutoProxy(exposeProxy = true)
  • 3、ApplicationContext
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

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

以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。

你可能感兴趣的