POSTGRESQL 实际上提供了三种隔离级别, 上次已经分析了其中的序列化的隔离级别,实际上在大部分数据库上这个级别都是不被使用的.
大部分数据库的隔离级别大部分是在 read commit 和 repeatable read 两个进行抉择的. 其中repeatable read 在我们的测试中,发现了一些问题, 在什么情况下会产生和serializable一样的情况. (具体请参见前面讲serializable)
我们来看看下面两个实验, 都是repeatable read 为什么结果会不一样.
1 SESSION A repeatable read SESSION B read commited
我们做以下的实验步骤 (按照序号整理顺序)
SESSION A
1
begin transaction isolation level repeatable read;
2
update employee set name = 'simon' where id = 1;
SESSION B
3 begin;
4 update employee set name = '2' where id =1
(语句没有执行等待状态)
SESSION A
5 commit;
SESSION B
6 序号4 成功操作
具体结果请看下图 SESSION A
SESSION B
结果和大多数的网站上的介绍 repeatable read 的结果一致. 他们要的结果就是防止了幻读.
但实际上上面的测试是有漏洞的,我们进行实验2
我们将上面的操作在重做一次
SESSION A
SESSION B
大家可以看到结果,结果和上面的不一样了,SESSION B 无法commit 进程B 直接进行了回滚. 哪里出了问题.
大家注意SESSION B 中的第一行
begin transaction isolation level repeatable read;
上面两个实验告诉我们什么??????
在POSTGRESQL 中如果你将事务的隔离级别调整成 repleatable read;
那么在某些时刻你的事务,会变成serializable 也就是变成序列化.
(具体看前几期关于serializable的实验结果)
那么为什么,我们来分析一下
为什么两个进程都是 REPEATABLE READ DML 同一行就产生了 序列化的可能
REPEATABLE READ 主要要完成什么任务, 防止幻读
当进程 A 占有了ID =1 这行后, 这行的信息就被锁定了,未来防止B进程修改这行数据,并读取这行数据是B 修改后的, A 必然要防止 B 修改这行数据,也就产生了序列化的概念, 我做完,你在做.
SESSION A
SESSION B
所以实际上网上大部分的例子都是在READ COMMIT中,产生一个REPATEABLE READ ,的结果,而不是你将你的系统调整成 REPATEABLE READ 后的结果,而如果你将你的POSTGRESQL 的数据库调整成REPATABLE READ 则那你事务回滚的概率会大大提高, 所以这个实验很明确的告诉大部分使用者, POSTGRESQL 建议你没有特殊需求还是使用 READ COMMIT 比较合适, POSTGRESQL 默认安装后的隔离级别也是READ COMMIT
