File tree 1 file changed +2
-2
lines changed
1 file changed +2
-2
lines changed Original file line number Diff line number Diff line change @@ -263,7 +263,7 @@ SELECT COUNT(*)FROM emails WHERE recipient_id = 2 AND unread_flag = true
263
263
通过防止脏写,这个隔离级别避免了一些并发问题:
264
264
265
265
- 如果事务更新多个对象,脏写会导致不好的结果。例如,考虑 [ 图 7-5] ( img/fig7-5.png ) ,以一个二手车销售网站为例,Alice 和 Bob 两个人同时试图购买同一辆车。购买汽车需要两次数据库写入:网站上的商品列表需要更新,以反映买家的购买,销售发票需要发送给买家。在 [ 图 7-5] ( img/fig7-5.png ) 的情况下,销售是属于 Bob 的(因为他成功更新了商品列表),但发票却寄送给了 Alice(因为她成功更新了发票表)。读已提交会防止这样的事故。
266
- - 但是,读已提交并不能防止 [ 图 7-1] ( img/fig7-1.png ) 中两个计数器增量之间的竞争状态。在这种情况下,第二次写入发生在第一个事务提交后,所以它不是一个脏写。这仍然是不正确的,但是出于不同的原因,在 “[ 防止更新丢失 ] ( #防止丢失更新 ) ” 中将讨论如何使这种计数器增量安全。
266
+ - 但是,读已提交并不能防止 [ 图 7-1] ( img/fig7-1.png ) 中两个计数器增量之间的竞争状态。在这种情况下,第二次写入发生在第一个事务提交后,所以它不是一个脏写。这仍然是不正确的,但是出于不同的原因,在 “[ 防止丢失更新 ] ( #防止丢失更新 ) ” 中将讨论如何使这种计数器增量安全。
267
267
268
268
![ ] ( img/fig7-5.png )
269
269
@@ -845,7 +845,7 @@ WHERE room_id = 123 AND
845
845
846
846
在同一个事务中,客户端在不同的时间点会看见数据库的不同状态。** 快照隔离** 经常用于解决这个问题,它允许事务从一个特定时间点的一致性快照中读取数据。快照隔离通常使用 ** 多版本并发控制(MVCC)** 来实现。
847
847
848
- * 更新丢失
848
+ * 丢失更新
849
849
850
850
两个客户端同时执行 ** 读取 - 修改 - 写入序列** 。其中一个写操作,在没有合并另一个写入变更情况下,直接覆盖了另一个写操作的结果。所以导致数据丢失。快照隔离的一些实现可以自动防止这种异常,而另一些实现则需要手动锁定(` SELECT FOR UPDATE ` )。
851
851
You can’t perform that action at this time.
0 commit comments