使用可重复读隔离级别，仍然有可能丢失更新（第二个丢失更新问题）。例如，在隔离级别设置为 RR 的场景中：
1) 事务 t1 从行 r1 读取数据，
2) 事务 t2 从行 r1 读取相同的数据，
3) t1 修改 #1 中读取的数据并将数据提交到 r1
4) t2修改 #2 中读取的数据并将数据提交到 r1。 t1 的更新丢失
我用 Hibernate 尝试了此操作（隔离级别设置为 RR），并看到了如上所述的行为。
那么为什么说通过 RR 隔离我们不会出现第二次丢失更新问题呢？
With repeatable read isolation level, it is still possible to lose updates (second lost updates problem). E.g. in the scenario with isolation level set to RR:
1) transaction t1 reads data from row r1,
2) transaction t2 reads same data from row r1,
3) t1 modifies the data read in #1 and commits data to r1
4) t2 modifies the data read in #2 and commits data to r1. t1's update is lost
I tried this with Hibernate (isolation level set to RR) and saw the behavior as mentioned above.
Why then is it said that with RR isolation we do not get second lost updates problem?
发布评论
评论（2）
您可以推断出，在您在此测试中使用的 MySQL 版本中，实现并不真正符合可重复读取，就像您在其他问题中所说的那样，因为如果你已经做了
事务 t2在步骤 4 中再次
那么 t2 就会读取 t1 在步骤 3 中保存的值。
所以你一开始就没有可重复读，所以不属于可重复读丢失更新的情况。
而不是像您一开始所想的那样当您说时
这是因为
事实上，一个例子是 READ_COMMITED 实现SQL 服务器。
丢失的更新不是这种现象之一，而是在对 ANSI SQL 隔离级别的批评中 Argeman在另一个问题解释了可重复读取保证不丢失更新：
P1 = 不可重复读取
P4 = 丢失更新
P2 的宽松解释（指定可能导致
到异常）是
P2 的严格解释（指定实际异常），称为 A1 是
而丢失更新的解释是
您提出的情况采用以下形式：
乍一看，这似乎是一种情况，但并不具有不可重复读取，事实上 t1 将始终在整个事务中读取相同的 x 值。
但如果我们关注 t2 并反转数字，我们可以看到这显然是不可重复读取的情况。
You can deduce that in the version of MySQL that you used in this test, the implementation doesn't really conform to Repeatable Read, like you say in your other question, because if you have done
again in the step 4 instead of
then the t2 would have read it the value saved by t1 in the step 3.
So you don't have repeteable read at first, so it is not a case of repeteable read with lost update.
and not in terms of locks like you thought at first when you said
This is because
In fact one example of this is the READ_COMMITED implementation from SQL SERVER.
The lost updates is not one of this phenomena, but in A Critique of ANSI SQL Isolation Levels pointed out by Argeman in the other question is explained that repeteable read guarantees no lost updates:
P1 = Non-repeteable reads
P4 = Lost updates
The loose interpretation of P2 (specifies a phenomenon that might lead
to an anomaly) is
The strict interpretation of P2 (specifies an actual anomaly), called A1 is
While the interpretation of lost updates is
The case that you present is in the form of:
At first it seems that is a case that doesn't have non-repeteable reads, in fact the t1 will always read the same value of x along the whole transaction.
But if we focus on the t2 and invert the numbers we can see that is clearly a case of non-repeteable read.
我已经用 MySQL 尝试了上述实验，看起来 MySQL 实现了不同的 RR 概念： MySQL可重复读和丢失更新/幻读
I had tried the above experiment with MySQL, and looks like MySQL implements a different notion of RR: MySQL repeatable read and lost update/phantom reads