• 事务传播范围,隔离界别


    本节思维导图

     

     

    事务管理是应用系统开发中必不可少的一部分。Spring 为事务管理提供了丰富的功能支持。Spring 事务管理分为编程式和声明式两种。编程式事务指的是通过编码方式实现事务;声明式事务基于 AOP,将具体的逻辑与事务处理解耦。生命式事务管理使业务代码逻辑不受污染,因此实际使用中声明式事务用的比较多。

    声明式事务有两种方式,一种是在配置文件(XML)中做相关的事务规则声明,另一种是基于 @Transactional 注解的方式。本文着重介绍基于 @Transactional 注解的事务管理。

    需要明确几点:

    • 默认配置下 Spring 只会回滚运行时、未检查异常(继承自 RuntimeException 的异常)或者 Error。
    • @Transactional 注解只能应用到 public 方法才有效。

    事务的实现原理

    事务的实现原理。如果说你加了一个 @Transactional 注解,此时 Spring 会使用 AOP 思想,对你的这个方法在执行之前,先去开启一个事务。执行完毕之后,根据你的方法是否报错,来决定回滚还是提交事务。

    @Transactional 注解的属性介绍

    下面分别介绍一下 @Transactional 的几个属性

    value 和 transactionManager 属性

    它们两个是一样的意思。当配置了多个事务管理器时,可以使用该属性指定选择哪个事务管理器。

    isolation 属性

    事务的隔离级别,默认值为 Isolation.DEFAULT。可选的值有

    • Isolation.DEFAULT:使用底层数据库默认的隔离级别
    • Isolation.READ_UNCOMMITTED:读取未提交数据(会出现脏读,不可重复读)基本不使用
    • Isolation.READ_COMMITTED:读取已提交数据(会出现不可重复读和幻读)
    • Isolation.REPEATABLE_READ:可重复读(会出现幻读)
    • Isolation.SERIALIZABLE:串行化

    tip:

    • MySQL 默认为 REPEATABLE_READ 级别
    • SQL_SERVER 默认为 READ_COMMITED 级别
    • 脏读:一个事务读取到另一个事务未提交的更新数据
    • 不可重复读:同一事务中,多次读取同一数据返回的结果有所不同,即,后续读取可以读到另一事务已提交的更新数据
    • 可重复读:在同一事务中多次读取数据时,能够保证所读数据一样,也就是后续读取不能读到另一事务已提交的更新数据
    • 幻读:一个事务读到另一个事务已提交的 insert 数据。

    timeout 属性

    事务的超时时间,默认值为 -1。如果超过该时间限制但事务还没有完成,则自动回滚事务。

    readOnly 属性

    指定事务是否为只读事务,默认值为 false;为了忽略那些不需要事务的方法,比如读取数据,可以设置 read-only 为 true

    rollbackFor 属性

    用于指定能够触发事务回滚的异常类型,可以指定多个异常类型

    noRollbackFor 属性

    抛出指定的异常类型,不会滚事务,也可以指定多个异常类型

    propagation 属性

    事务的传播行为,默认值为 Propagation.REQUIRED。可选的值有:

    • PROPAGATION.REQUIRED:如果当前没有事务,则创建一个新事务。如果当前存在事务,就加入该事务。该设置是最常用的设置。
    • PROPAGATION.SUPPORTS:支持当前事务,如果当前存在事务,就加入该事务。如果当前不存在事务,就以非事务执行。
    • PROPAGATION.MANDATORY:支持当前事务,如果当前存在事务,就加入该事务,如果当前不存在事务,就抛出异常。
    • PROPAGATION.REQUIRE_NEW:创建新事务,无论当前存不存在事务,都创建新事务。
    • PROPAGATION.NOT_SUPPORTED:以非事务方式执行操作,如果当前事务存在,就把当前事务挂起。
    • PROPAGATION.NEVER:以非事务方式执行,如果当前存在事务,则抛出异常。
    • PROPAGATION.NESTED:如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则按 REQUIRED 属性执行。

    @Transactional 的 propagation 属性代码示例

    比如如下代码,save 方法首先调用 method1 方法,然后抛出了异常,就会导致事务回滚,如下两条数据都不会插入数据库。

    @Transactional(propagation = Propagation.REQUIRED)
    public void save() {
    	
    	method1();
    	
    	User user = new User("服部半藏");
    	userMapper.insertSelective(user);
    	
    	if(true) {
    		throw new RuntimeException("save 抛异常了");
    	}
    }
    
    public void method1() {
    	User user = new User("宫本武藏");
    	userMapper.insertSelective(user);
    }

    现在有需求如下,就算 save 方法的后面抛异常了,也不能影响 method1 方法的数据插入。一般方法时给 method1 加入一个新的事务,这样 method1 就会在这个新的事务中执行,原来的事务不会影响到新的事务。例如给 method1 加 propagation 属性为 Propagation.REQUIRES_NEW 的事务。

    @Transactional(propagation = Propagation.REQUIRED)
    public void save() {
    	
    	method1();
    	
    	User user = new User("服部半藏");
    	userMapper.insertSelective(user);
    	
    	if(true) {
    		throw new RuntimeException("save 抛异常了");
    	}
    }
    
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void method1() {
    	User user = new User("宫本武藏");
    	userMapper.insertSelective(user);
    }

    运行之后,发现并没有起作用,数据也是没有插入数据库。通过查看日志发现,两个方法都是处于同一个事务中,method1 方法并没有创建一个新的事务。


     

    通过 Spring 官方文档可以知道:在默认的代理模式下,只有目标方法由外部调用,才能被 Spring 的事务拦截器拦截。在同一个类中的两个方法直接调用,是不会被 Spring 的事务拦截器拦截,就像上面的 save 方法直接调用了同一个类中 method1 方法,method1 方法不会被 Spring 的事务拦截器拦截。可以使用 AspectJ 取代 Spring AOP 代理来解决这个问题。但是这里不展开。

    为了解决这个问题,我们可以新建一个类:

    @Service
    public class OtherServiceImpl implements OtherService {
    
    	@Autowired
    	private UserMapper userMapper;
    	
    	@Transactional(propagation = Propagation.REQUIRES_NEW)
    	public void method1() {
    		User user = new User("风魔小太郎");
    		userMapper.insertSelective(user);
    	}
    }

    然后再 save 方法中调用 otherService.method1 方法

    @Autowired
    private OtherService otherService;
    
    @Transactional(propagation = Propagation.REQUIRED)
    @Override
    public void save() {
    
        otherService.method1();
    
        User user = new User("服部半藏");
        userMapper.insertSelective(user);
    
        if (true) {
            throw new RuntimeException("save 抛异常了");
        }
    }

    这下,otherService.method1 方法的数据插入成功,save 方法的数据未插入,事务回滚。继续查看日志:

     


     

    从日志可以看出,首先创建了 save 方法的事务,由于 otherService.method1 方法的 @Transactional 的 propagation 属性为 Propagation.REQUIRES_NEW,所以接着暂停了 save 方法的事务,重新创建了 otherService.method1 方法的事务,接着 otherService.method1 方法的事务提交,接着 save 方法的事务回滚,这就印证了只有目标方法由外部调用,才能被 Spring 的事务拦截器拦截。

    Spring 事务传播机制总结

    Spring 事务传播机制总共有 7 种,其中使用最多的应该是 PROPAGATION_REQUIRES、PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED。其中所谓的嵌套事务,是指外层的事务如果回滚,会导致内层的事务也回滚;但是内层的事务如果回滚,仅仅是滚回自己的代码。

    比如现在有一段业务代码,方法 A 调用方法 B,我希望的是如果方法 A 出错了,此时仅仅回滚方法 A,不能回滚方法 B,这个时候可以给方法 B 使用 REQUIRES_NEW 传播机制,让他们两的事务是不同的。

    如果方法 A 调用方法 B,如果出错,方法 B 只能回滚它自己,方法 A 可以带着方法 B 一起回滚。那这种情况可以给方法 B 加上 NESTED 嵌套事务。

    https://zhuanlan.zhihu.com/p/157646604

  • 相关阅读:
    前端常见跨域解决方案
    前端必须要懂的浏览器缓存机制
    判断一个变量是数组还是对象
    javascript中Array常用方法
    Javascript数据类型
    Email接收验证码,以实现登录/注册/修改密码
    web安全之机器学习入门——3.2 决策树与随机森林
    web安全之机器学习入门——3.1 KNN/k近邻
    web安全之机器学习入门——2.机器学习概述
    cmd下的一些小技巧
  • 原文地址:https://www.cnblogs.com/albertzhangyu/p/14357497.html
Copyright © 2020-2023  润新知