为什么它在 Oracle 文档的 Read Committed Transactions 示例中是“丢失更新”？

Question

在《Oracle 数据库概念》一书中，Oracle 给出了一个例子来解释Read Committed Isolation Level。

在示例中，事务 1 更新第 1 行，然后事务 2 在事务 1 提交之前更新同一行。因此，事务 2 一直等到事务 1 提交。然后事务 1 提交。之后事务 2 提交。当然，事务 2 提交后，事务 1 对第 1 行的更新会被事务 2 覆盖。

它将这种情况视为lost update。但在我看来，它不应该是“丢失的更新”，因为事务 1 已经提交。在单个事务中考虑丢失的更新。无论读取操作如何，该调度甚至等于可序列化调度。

这个例子是here，或者更具体地说是here。

在 Oracle 的词汇表中，丢失的更新是 -

数据完整性问题，其中一个数据写入者会覆盖修改相同数据的不同写入者的更改。

那么，您对此有何看法？是否是“丢失更新”，如果是，是否可以通过数据库的并发控制来避免这种丢失更新？

任何 cmets 和帮助将不胜感激。

Answer 1

这被认为是“丢失的更新”，因为会话 2 覆盖了会话 1 所做的更改，而没有意识到它正在这样做。就 Session 2 而言，它读取了薪水为 6200 的“Banda”行并将其更新为 6300 - 它从未看到 Session 1 的更新为 7000。

正如该文档所述：“设计处理丢失更新的策略是应用程序开发的重要组成部分”——即它不是 DBMS 内置数据并发功能的一部分。在事务中，这可以通过使用select for update 尝试锁定行来完成。在此示例中，如果会话 2 执行此操作，则会阻止对“Banda”行的选择。会话 1 提交后，会话 2 将获得锁并且将看到新的薪水。在无状态环境中，如 Web 应用程序 optimistic locking 用于实现此目的。