老生常谈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

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

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

最新评论