十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
设置一个事务的隔离级别
创新互联建站专注于广东企业网站建设,自适应网站建设,成都做商城网站。广东网站建设公司,为广东等地区提供建站服务。全流程按需策划,专业设计,全程项目跟踪,创新互联建站专业和态度为您提供的服务
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
ET TRANSACTION READ ONLY;
设置增个会话的隔离级别
ALTER SESSION SET ISOLATION_LEVEL SERIALIZABLE;
ALTER SESSION SET ISOLATION_LEVEL READ COMMITTED;
先来总体说一下我对这个问题的理解,用一句话概括:
数据库是可以控制事务的传播和隔离级别的,Spring在之上又进一步进行了封装,可以在不同的项目、不同的操作中再次对事务的传播行为和隔离级别进行策略控制。
注意:Spring不仅可以控制事务传播行为(PROPAGATION_REQUIRED等),还可以控制事务隔离级别(ISOLATION_READ_UNCOMMITTED等)。
(以下是个人理解,如果有瑕疵请及时指正)
下面我具体解释一下:
为了大家能够更好的理解,先来明确几个知识点:
事务的传播行为:简单来说就是事务是手动提交还是自动提交,事务什么时候开始,什么时候提交。
事务的隔离级别:简单来说,就四个,提交读,提交读,重复读,序列化读。
首先我来描述一下,数据库(mysql)层面上对于事务传播行为和隔离级别的配置和实验方法:
数据库层面(采用命令行):其实mySql命令行很简单,希望实验操作一下:
//连接数据库,我这里是本地,后面是用户名密码,不要打分号,如果指令不行,配置下环境变量,网上有很多。
1. cmd中执行:mysql -hlocalhost -uroot -pmysql
//查看本地数据库事务传播行为是手动提交(0),还是自动提交(1)。
2.select @@autocommit;
//如果是0,希望设置为手动提交,这里其实是设置本对话的autocommit,因为如果你再开一个cmd,发现还是没改回来,如果想修改全局的,网上有global方法。
3.set @@autocommit=0;
//然后查询本地数据库中的一条记录,我本地数据库为test1;
4.use test1;
5.select * from task where taskid=1;
//同时新开一个窗口cmd,连接数据库,并且修改这条记录,update语句我就不写了,或者直接修改数据库本条记录。
//再次执行select * from task where taskid=1;发现值没变。OK因为此时数据库隔离级别为repeatable read 重复读,因为mysql默认的隔离级别是重复读。
//修改数据库隔离级别
6.set global transaction isolation level read committed;
//查看一下,可能需要重新连接一下
7.select @@tx_isolation;
//这时在执行一下4,5操作,发现值变了,ok。因为已经改变了数据库隔离级别,发生了重复读出不同数据的现象。
(以上操作希望有不明白的上网自学一下,很有用,先把数据库隔离级别弄明白了)
然后再来讲一下,Spring对事务传播行为和隔离级别的二次封装。
因为不同项目可能在一个mysql的不同数据库上,所以可以在项目中配置数据库的传播行为和隔离级别:
关于spring的传播行为(PROPAGATION_REQUIRED、PROPAGATION_REQUIRED等),我《数据库隔离级别(mysql+Spring)与性能分析 》文章中有讲,网上也有很多相关资料,我就不说了。
关于spring的事务隔离级别与数据库的一样,也是那四个,多了一个default,我也不仔细讲了。
下面主要讲一下spring的配置方法:
property name="transactionAttributes"
props
prop key="save*"PROPAGATION_REQUIRED/prop
prop key="update*"PROPAGATION_REQUIRED/prop
prop key="delete*"PROPAGATION_REQUIRED/prop
prop key="get*"PROPAGATION_REQUIRED,readOnly/prop
prop key="find*"PROPAGATION_REQUIRED,ISOLATION_READ_UNCOMMITTED/prop
/props
就以find为例,可以配置这么配置,前面是控制传播行为,后面是控制事务隔离级别的。那么这时哪怕数据库层面上是重复读,但是还是以这里为准,你会发现在同一个事务中两次查询的结果是不一样的。
最后扫除一个盲区,readonly这个属性,是放在传播行为中的,一般书都这么归类,我也尝试了一下,readonly并不能影响数据库隔离级别,只是配置之后,不允许在事务中对数据库进行修改操作,仅此而已。
1.查看当前会话隔离级别
select @@tx_isolation;
2.查看系统当前隔离级别
select @@global.tx_isolation;
3.设置当前会话隔离级别
set session transaction isolatin level repeatable read;
4.设置系统当前隔离级别
set global transaction isolation level repeatable read;
5.命令行,开始事务时
set autocommit=off 或者 start transaction
关于隔离级别的理解
1.read uncommitted
可以看到未提交的数据(脏读),举个例子:别人说的话你都相信了,但是可能他只是说说,并不实际做。
2.read committed
读取提交的数据。但是,可能多次读取的数据结果不一致(不可重复读,幻读)。用读写的观点就是:读取的行数据,可以写。
3.repeatable read(MySQL默认隔离级别)
可以重复读取,但有幻读。读写观点:读取的数据行不可写,但是可以往表中新增数据。在MySQL中,其他事务新增的数据,看不到,不会产生幻读。采用多版本并发控制(MVCC)机制解决幻读问题。
4.serializable
可读,不可写。像java中的锁,写数据必须等待另一个事务结束。
Oracle通过在undo表空间中构造多版本数据块来实现读一致性,支持serializable的隔离级别,可以实现最高级别的读一致性。
每个session查询时,如果对应的数据块发生变化,Oracle会在undo表空间中为这个session构造它查询时的旧的数据块。
oracle数据库通过这种能力,来保证在serializable级别的时候,不是锁表不让其他事务插入或删除,而是其他事务能操作,本事务中的多次查询还是使用旧数据块,以此达到事务间多次查询的记录的一致性。
感觉就是序列隔离级别是最独立的。这个效果,不正是你想要的么?