数据库中存在读异常和写异常。
所谓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还有很大的优化空间。