ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

对snapshot isolation和write-snapshot isolation的一些思考

2019-08-21 11:55:04  阅读:202  来源: 互联网

标签:isolation T1 write snapshot 解决 异常


数据库中存在读异常写异常

所谓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还有很大的优化空间。

标签:isolation,T1,write,snapshot,解决,异常
来源: https://www.cnblogs.com/slontia/p/11387891.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有