
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
关于隔离级别的理解
先来总体说一下我对这个问题的理解,用一句话概括:数据库是可以控制事务的传播和隔离级别的,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并不能影响数据库隔离级别,只是配置之后,不允许在事务中对数据库进行修改 *** 作,仅此而已。
修改方法
有两种方法可以对配置了 systemd 的程序进行资源隔离:1. 命令行修改:通过执行 systemctl set-property 命令实现,形式为 systemctl set-property name parameter=value;修改默认即时生效。2. 手工修改文件:直接编辑程序的 systemd unit file 文件,完成之后需手工执行 systemctl daemon-reload 更新配置,并重启服务 systemctl restart name.service。
systemd unit file 里支持的资源隔离配置项,如常见的:
CPUQuota=value
该参数表示服务可以获取的最大 CPU 时间,value 为百分数形式,高于 100% 表示可使用 1 核以上的 CPU。与 cgroup cpu 控制器 cpu.cfs_quota_us 配置项对应。
MemoryLimit=value
该参数表示服务可以使用的最大内存量,value 可以使用 K, M, G, T 等后缀表示值的大小。与 cgroup memory 控制器 memory.limit_in_bytes 配置项对应。
事务的4种隔离级别
READ UNCOMMITTED 未提交读,可以读取未提交的数据。READ COMMITTED 已提交读,对于锁定读(select with for update 或者 for share)、update 和 delete 语句, InnoDB 仅锁定索引记录,而不锁定它们之间的间隙,因此允许在锁定的记录旁边自由插入新记录。 Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ 可重复读,事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE 序列化
在了解了 4 种隔离级别的需求后,在采用锁控制隔离级别的基础上,我们需要了解加锁的对象(数据本身&间隙),以及了解整个数据范围的全集组成。
数据范围全集组成
SQL 语句根据条件判断不需要扫描的数据范围(不加锁);
SQL 语句根据条件扫描到的可能需要加锁的数据范围;
以单个数据范围为例,数据范围全集包含:(数据范围不一定是连续的值,也可能是间隔的值组成)
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)