From 95f51ebdf6e8374e9094cb66764816d96202c25b Mon Sep 17 00:00:00 2001 From: Winy Song <40143136+Ynjxsjmh@users.noreply.github.com> Date: Wed, 12 Oct 2022 16:40:00 +0800 Subject: [PATCH] =?UTF-8?q?Fix=20=E2=80=9C=E6=9B=B4=E6=96=B0=E4=B8=A2?= =?UTF-8?q?=E5=A4=B1=E2=80=9D=20to=20=E2=80=9C=E4=B8=A2=E5=A4=B1=E6=9B=B4?= =?UTF-8?q?=E6=96=B0=E2=80=9D=20in=20ch7.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 第一处 原文： > However, read committed does not prevent the race condition between two > counter increments in Figure 7-1. In this case, the second write happens after the > first transaction has committed, so it’s not a dirty write. It’s still incorrect, but for > a different reason—in **“Preventing Lost Updates”** on page 242 we will discuss how > to make such counter increments safe. 翻译： > 但是，读已提交并不能防止 [图 7-1](https://github.com/Vonng/ddia/blob/master/img/fig7-1.png) 中两个计数器增量之间的竞争状态。在这种情况下，第二次写入发生在第一个事务提交后，所以它不是一个脏写。这仍然是不正确的，但是出于不同的原因，在 **“[防止更新丢失](https://github.com/Vonng/ddia/blob/master/ch7.md#%E9%98%B2%E6%AD%A2%E4%B8%A2%E5%A4%B1%E6%9B%B4%E6%96%B0)”** 中将讨论如何使这种计数器增量安全。 -------------- 第二处 原文： > **Lost updates** > Two clients concurrently perform a read-modify-write cycle. One overwrites the > other’s write without incorporating its changes, so data is lost. Some implemen‐ > tations of snapshot isolation prevent this anomaly automatically, while others > require a manual lock (SELECT FOR UPDATE). 翻译： > **更新丢失** > 两个客户端同时执行 读取 - 修改 - 写入序列。其中一个写操作，在没有合并另一个写入变更情况下，直接覆盖了另一个写操作的结果。所以导致数据丢失。快照隔离的一些实现可以自动防止这种异常，而另一些实现则需要手动锁定（SELECT FOR UPDATE）。 --- ch7.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch7.md b/ch7.md index 0debe88..3cb0660 100644 --- a/ch7.md +++ b/ch7.md @@ -263,7 +263,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true 通过防止脏写，这个隔离级别避免了一些并发问题： - 如果事务更新多个对象，脏写会导致不好的结果。例如，考虑 [图 7-5](img/fig7-5.png)，以一个二手车销售网站为例，Alice 和 Bob 两个人同时试图购买同一辆车。购买汽车需要两次数据库写入：网站上的商品列表需要更新，以反映买家的购买，销售发票需要发送给买家。在 [图 7-5](img/fig7-5.png) 的情况下，销售是属于 Bob 的（因为他成功更新了商品列表），但发票却寄送给了 Alice（因为她成功更新了发票表）。读已提交会防止这样的事故。 -- 但是，读已提交并不能防止 [图 7-1](img/fig7-1.png) 中两个计数器增量之间的竞争状态。在这种情况下，第二次写入发生在第一个事务提交后，所以它不是一个脏写。这仍然是不正确的，但是出于不同的原因，在 “[防止更新丢失](#防止丢失更新)” 中将讨论如何使这种计数器增量安全。 +- 但是，读已提交并不能防止 [图 7-1](img/fig7-1.png) 中两个计数器增量之间的竞争状态。在这种情况下，第二次写入发生在第一个事务提交后，所以它不是一个脏写。这仍然是不正确的，但是出于不同的原因，在 “[防止丢失更新](#防止丢失更新)” 中将讨论如何使这种计数器增量安全。 ![](img/fig7-5.png) @@ -845,7 +845,7 @@ WHERE room_id = 123 AND 在同一个事务中，客户端在不同的时间点会看见数据库的不同状态。**快照隔离** 经常用于解决这个问题，它允许事务从一个特定时间点的一致性快照中读取数据。快照隔离通常使用 **多版本并发控制（MVCC）** 来实现。 -* 更新丢失 +* 丢失更新 两个客户端同时执行 **读取 - 修改 - 写入序列**。其中一个写操作，在没有合并另一个写入变更情况下，直接覆盖了另一个写操作的结果。所以导致数据丢失。快照隔离的一些实现可以自动防止这种异常，而另一些实现则需要手动锁定（`SELECT FOR UPDATE`）。