Spring事务隔离级别与数据库隔离级别不一致时,该以谁为准?

《SQL、NoSQL》 专栏收录该内容
21 篇文章 2 订阅

原创博文,欢迎转载,转载时请务必附上博文链接,感谢您的尊重。

前言

通过本篇,你将了解到【Spring事务】与【数据库事务】的关系,以及优先级问题,我将为你一一论证。

阅读本篇,你可能会需要的博文:


正文

数据库是可以控制事务的传播和隔离级别的,Spring在之上又进一步进行了封装,可以在不同的项目、不同的操作中再次对事务的传播行为和隔离级别进行策略控制。

所以说,spring事务本质上使用数据库事务,而数据库事务本质上使用数据库锁,所以spring事务本质上使用数据库锁,开启spring事务意味着使用数据库锁。

上面的“总结”来自网络,结合自身理解与实践,的确可以最为一句精华,本文内容主要围绕这句话展开,以2个问题的形式阐明观点。

  1. Spring定义的隔离级别和数据库设置的隔离级别,二者是什么关系?
  2. 如果Spring定义的隔离级别和数据库设置的隔离级别不一样,以谁的为准?

一、两者的关系

详情在我的其他博文都有具体介绍(需要的朋友见本文【前言】提示),这里就不赘述了,我们直接对比结果。

1. 数据库的隔离级别:

MySQL 默认为 :EPEATABLE_READ;Oracle,sql server 默认为:READ_COMMITTED;READ_UNCOMMITTED 由于隔离级别较低,通常不会被使用。

√: 可能出现    ×: 不会出现
隔离级别隔离级别的值脏读不可重复读幻读
Read uncommitted(未提交读)0
Read committed(已提交读)1×
Repeatable read(可重复读)2××
Serializable(可串行化)3×××

2. Spring事务的隔离级别:

Spring事务由 @Transactional 注解实现,隔离级别由它的参数 isolation 控制,Isolation 的 Eum 类中定义了“五个”表示隔离级别的值,如下。

√: 可能出现    ×: 不会出现
Isolation的值与隔离级别隔离级别的值脏读不可重复读幻读
Isolation.DEFAULT0---
Isolation.READ_UNCOMMITTED1
Isolation.READ_COMMITTED2×
Isolation.REPEATABLE_READ4××
Isolation.SERIALIZABLE8×××

Isolation.DEFAULT 是 PlatfromTransactionManager 默认的隔离级别,它的含义是:使用数据库默认的事务隔离级别

除此之外,另外四个与 JDBC 的隔离级别是相对应的,就好像 Java 里的重写一样,所以说:Spring事务隔离级别是在数据库隔离级别之上又进一步进行了封装。

二、 不一致会怎样

既然是封装,那么Spring项目应该就是以Spring事务为准的,除非使用 @Transactional(isolation = Isolation.DEFAULT)时,才会使用数据库设置的隔离级别。

为了验证这个猜想,我们还是找到源码解读一下,从JDBC开始说起吧。

1. JDBC 加载流程

每一个 Spring 事务管理,都涉及到了与数据库的交互,也必然涉及到了JDBC连接。

JDBC 加载的流程还记得吧,肯定都被问过,有四步:注册驱动,建立连接,发起请求,输出结果。写一段伪代码:

    Connection conn = null;
    Statement stmt = null;
    ResultSet rs = null;
    try{
        // 1.注册 JDBC 驱动
        Class.forName("com.mysql.jdbc.Driver");
        // 2.创建链接
        System.out.println("连接数据库...");
        conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/my_db","root","root");
        // 3.发起请求
        stmt = conn.createStatement();
        String sql = "SELECT id, name, url FROM websites";
        rs = stmt.executeQuery(sql);
        // 4.输出结果
        System.out.print("查询结果:" + rs);
        // 关闭资源(演示代码,不要纠结没有写在finally中)
        rs.close();
        stmt.close();
        conn.close();
    } catch (SQLException se)
        se.printStackTrace();
    }catch(Exception e){
        e.printStackTrace();
    }

在创建连接阶段,JDBC 从数据库获取一个连接 Connection 对象,该对象不仅有连接数据库的方法,还有设置当前连接的事物隔离级别的方法。

2. Connection  源码解释

Connection 实体类中包含了 void setTransactionIsolation(int level) throws SQLException;设置设置当前连接的事物隔离级别的方法。

Spring 约定了使用 @Transactional 注解的形式实现事务特性,而隔离级别的开启,也是注解的形式实现,如:开启事务的串行级别 —— @Transactional(isolation = Isolation.SERIALIZABLE)。

源码截不全,我复制一下:

/**
* 这是 Connection 连接的部分源码
*/
public interface Connection  extends Wrapper, AutoCloseable {

    ... 

    /**
    * 尝试将此连接对象的事务隔离级别更改为给定的级别
    * 接口连接中定义的常量是可能的事务隔离级别
    */
    void setTransactionIsolation(int level) throws SQLException;

    ...
}

该方法的注释说明:尝试将此连接对象的事务隔离级别更改为给定的级别,如果在事务期间调用此方法,则结果由实现定义。

没错,强调的就是本次连接 Connection,所以,如果spring与数据库事务隔离级别不一致时,以spring为准。

3. 验证

阐述一下方法:

  • 首先,验证测试数据库的隔离级别 Select @@tx_isolation;
  • 写一个包含update,save的与测试数据库交互的方法;
  • 分别验证加上@Transactional(isolation = Isolation.SERIALIZABLE)注解前后,测试数据库的隔离级别是否变化!!

以我的测试数据库为例,结果没有发生变化,都是 READ_COMMITTED。

这只是简单的验证下Spring事务隔离级别的修改,是否会直接影响数据库的隔离级别,结论是没有。

不太严谨,但是证明了我的猜想,后期我会在Sping项目中,通过测试代码进一步验证“修改隔离级别以成功运用到Spring事务中”。

三、总结

  • 数据库是可以控制事务的传播和隔离级别的,Spring在之上又进一步进行了封装,可以在不同的项目、不同的操作中再次对事务的传播行为和隔离级别进行策略控制;
  • 项目中,以 Spring 事务为准,因为他重写了数据库的隔离级别,但没有直接修改数据库的隔离级别;
  • 项目中,如果 Spring 事务隔离级别设置为(isolation = Isolation.DEFAULT)默认数据库优先时,以数据库的隔离级别为准。

小编怀着忐忑的心情,上传了本篇博文,如果有错误,还请大佬指正!!后期也会补全自己的验证手段!!

That's all,thank you!


我是IT无知君,您的点赞、评论和关注,是我创作的动力源泉。
学无止境,气有浩然,让我们一起加油,天涯未远,江湖有缘再见!!

  • 7
    点赞
  • 1
    评论
  • 18
    收藏
  • 打赏
    打赏
  • 扫一扫,分享海报

评论1
请先登录 后发表评论~
©️2021 CSDN 皮肤主题: 技术黑板 设计师:CSDN官方博客 返回首页

打赏作者

Java Punk

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值