在 Vlad Mihalcea 的伟大博客的 Preventing lost updates in long conversations 中说
为了防止丢失更新，我们必须有 应用程序级可重复 与并发控制机制一起读取。
为什么我需要“应用程序级”可重复阅读？并发控制机制还不够吗？
注意：我以问答的方式写了这篇文章，因为阅读这篇文章让我怀疑使用 Hibernate + Optimistic Locking 的无状态后端的可能性。我已经做出了自己的结论（解释回答我自己的问题），但我仍然会犯错误或遗漏。
【问题讨论】：
标签： sql hibernate transactions isolation-level optimistic-locking
恕我直言存在三种丢失更新：
第一个必须在数据库级别处理，如果我们没有超过 我们工具带中的隔离级别绝对不能使用 READ_COMMITED。我们至少应该使用 REPETEABLE_READ 来保证数据的一致性。
如果我们的 RDBMS 使用两阶段锁定（如 SQL Server），并发性将受到影响，因为在读取查询中获得的共享锁将在事务结束（提交/回滚）时释放。
相反，如果我们的 RDBMS 使用 MVCC（如 PostgreSQL），则可重复读取事务中的每个查询都会看到事务中第一个非事务控制语句开始时的快照，并且只会阻塞写入操作，如果排他锁已被占用，这意味着另一个事务正在写入相同的数据，如果此事务成功，则等待的必须回滚（错误：由于并发更新而无法序列化访问）。
Hibernate 的乐观锁定使用与 PostgreSQL 中的 REPETEABLE_READ 相同的方法，并且都正确地避免了数据库级别的丢失更新。 主要区别在于 REPETEABLE_READ 不能考虑用户的思考时间，因为它不能进一步超出 pyshical 事务的边界，并且典型的 Web 应用程序需要在多个请求期间发生的读取-修改-写入会话模式。
在此对话中，可能有 2 到 3 个人修改了 Alice 在 1 处请求的产品，而 Alice 看不到该修改将被 Alice 3 中的请求覆盖。
这类似于“无状态对话反模式”。好吧，我不这么认为，因为这是类型 2 的丢失更新，必须通过域的验证规则来避免（图中未考虑）。
假设产品的最大库存为 10。 Alice 的请求类似于
POST /purchase
productId=1&quantity=3
然后处理该请求的服务将执行以下操作：
product = repository.retrieve(purchase.productId)
if (product.quantity + purchase.quantity <= 10)
product.quantity = product.quantity + purchase.quantity
repository.save(product)
return Http.OK
else
return Http.4XX
仍然真实的是，Alice 可能会根据旧数据进行购买。
问题在于，在这种情况下，我们没有考虑用户思考时间，这会导致类型 3 的更新丢失。 这里的解决方案是使用 N_VERSION 将乐观锁定推送到应用程序层，就像 Vlad 说的那样，但他没有考虑将 N_VERSION 发送到客户端，并且没有这个选项，我们可以拥有一个无状态的后端。 甚至休眠consider this option。 场景是：
可以说 N_VERSION 在 Javascript 客户端中很容易被破坏（即使我有 asked myself），但我们将有验证规则来维护业务不变量。
所以我不同意弗拉德。我认为我们只需要业务规则和并发控制机制：乐观或悲观锁定（尽管使用悲观锁定我们无法避免丢失类型 3 的更新）。
在我看来，应用程序级可重复读取的好处是使用扩展会话来维护请求之间的对象，从而避免在每个请求中重新获取它们。
【讨论】：
在logical transaction 中，您可以有 N 个物理事务和 N - 1 个用户思考时间。
用户思考时间也是逻辑事务的一部分，所以基本上你只有 1. 和 2.
我看不出如何在没有pessimistic locking 或乐观锁定的情况下在用户思考时间通过域模型验证来防止lost update。
使用悲观锁定，您可以防止丢失更新，但只能在最后一个物理事务中，但前提是您考虑在最后一个事务中加载的状态，而不是在开始时加载的状态。这破坏了应用程序级的可重复读取保证。
现在，您为什么还需要应用程序级的可重复读取？
答案与隔离级别可重复读取的情况相同。通过可重复读取，您知道从读取到写入有一个可序列化的流程。如果没有此保证，您可以允许丢失更新异常。数据库事务也保留相同的语义。加载项目后，您可以防止丢失更新 (2PL) 或检测它 (MVCCC)。应用程序级可重复读取也这样做，但在多请求逻辑事务的上下文中，因此您需要保留您读取的相同行值，并且需要强制执行锁定机制。由于悲观锁定不会扩展 对于多个请求，乐观锁定是唯一需要考虑的可行锁定机制。
所以，这种方法基本上是 MVCC 外推到多个请求。
【讨论】：