对snapshot isolation和write-snapshot isolation的一些思考
数据库中存在读异常和写异常。
所谓snapshot,目的在于保证事务执行的各个阶段,读相同的数据项得到的结果没有变化,这样一来就避免了不可重复读、幻读等读数据异常。
但是仅仅是读数据不变还不够,因为这样只是解决了读异常,却不能解决写异常,而对于写异常,可以从脏写、丢失更新和写偏序三种进行讨论。对于这些写异常,snapshot isolation通过避免WW冲突进行解决(无法解决写偏序),write-snapshot isolation通过避免RW冲突进行解决,但二者的共同点都是从根本上彻底消除了某一种冲突的存在。(对于这三种写异常的定义,参考了《数据库事务处理的艺术》P8和P10)
- 对于脏写,我认为依靠多版本机制就可以解决,在回滚时只要将本事务写入的版本删去即可,不影响其它事务写入的版本。
- 对于丢失更新,需要同时出现RW冲突和WW冲突,只要避免二者中任意一个即可解决,因此snapshot isolation和write-snapshot isolation都可以解决这个问题。
- 对于写偏序,一定会出现RW冲突,却不一定会出现WW冲突,因此snapshot isolation不能解决该异常,而write-snapshot isolation却可以解决。
由此不难看出,write-snapshot isolation是要比snapshot isolation更加严格的。但是,我认为write-snapshot isolation的并发度不一定比snapshot isolation更高,这一点可以从一下例子看出:
T1 |
T2 |
|
t0 |
R(A1) |
|
t1 |
W(A2) |
|
t2 |
W(B1) |
|
t3 |
Commit |
|
t4 |
Commit(失败) |
t0时刻,T1读取了数据项A,紧接着在t1时刻,T2对数据项A进行了更新。因此在t4时刻,T1检查读集会失败,导致T1事务回滚。而在snapshot isolation中,T1和T2事务都可以正常提交。
但这同样不能说明snapshot isolation的并发度要比write-snapshot isolation差,还要根据具体场景(读密集、写密集)再做判断。但是由此至少可以看出,write-snapshot isolation还有很大的优化空间。
最新文章
- [原] KVM 虚拟化原理探究(1)— overview
- javascript语言精粹摘要
- 【原创】Kakfa common包源代码分析
- 在c#中运行js脚本(将js文件生成为.dll文件)
- chaper3_exerise_Uva1225_digit_counting
- Windows下HG服务器的搭建
- MyEclipse------随机流(能读也能写数据)
- What is the difference between <;%, <;%=, <;%# and -%>; in ERB in Rails?
- &;nbsp; 与 空格的区别
- Class Model of Quick Time Plugin
- jQuery全屏插件Textarea Fullscreen
- Beyond Compare 3.3.8 build 16340 + Key
- 自己总结的C#编码规范--7.文档下载 &; 总结
- JDBC 链接mysql 8 的问题
- D1——初读《Head First Java》
- 20175314薛勐 Arrays和String单元测试
- ASP.NET Core MVC 源码学习:详解 Action 的匹配
- ASP.NET Core中代码使用X509证书,部署到IIS上后报错:System cannot find the specified file 的解决办法(转载)
- make[1]: *** [storage/perfschema/unittest/CMakeFiles/pfs_connect_attr-t.dir/all] 错误 2 解决方法
- java 常见语法,但是发现switch等基础,常见面试套路不会了,待补充