如何在用户思考时间介于两者之间的长对话中实现悲观锁定，以Hibernate为例？

Question

由于悲观锁只能应用于单个数据库事务。并且在用户思考时间内保持数据库事务打开，数据库中持有的锁被认为是反模式，那么在用户思考时间之间实现悲观锁的正确方法是什么？

我知道如何在与用户思考时间之间的长时间对话中实现乐观锁定，只是不知道如何在与用户思考时间之间的长时间对话中实现悲观锁定。

Answer 1

简短的回答是，没有“简单的配方”来做到这一点，也没有来自Hibernate或任何其他ORM框架的任何现成的解决方案。

长长的答案：

您必须了解如何实现一些特性，这些特性将允许您的应用程序模拟“长对话”的数据库锁定行为。

最重要的是，确保一旦用户开始使用一条信息（数据库行或一组对象，无论您的情况如何），该信息将不会被任何其他用户使用/操纵。此外，您还必须确保在用户完成操作时，或在一定时间后（您不希望信息被永久锁定），您有一些发布信息的策略。

由于我不知道你的应用程序的细节，我将给出一个抽象的例子，这可能会对你的案例有所启发。当然，这不是唯一的解决方案。

请记住，每一步都将包含在单个事务中，因为最终，您的长对话将是Web应用程序中的一系列请求。

此外，假设来自问题标签的信息，这个答案的目标是在一个连接到数据库的简单Web应用程序中找到一个解决方案。没有“花哨的异国情调”架构。

在需要这种控制的给定表中，添加两列:一列是用户ID，另一列是时间戳。这将控制谁拥有一行上的“锁”，以及获得锁的时间。

当用户开始使用表的行中包含的数据时，您的应用程序将使用用户ID和当前日期/时间更新该行。这是最重要的一步，因为您必须正确处理并发问题。如果不止一个用户试图获取该行的“锁”，则您的应用程序必须仅为一个用户让出锁。此步骤很可能需要在单个事务中使用数据库锁。请确保此步骤快速，并且不会附加到其他操作，这样数据库锁不会对应用程序产生很大影响。

用户操作完数据后，应用程序可以简单地将用户ID和时间戳设置为空，之后其他用户将能够使用它。

如果用户由于某种原因没有完成任务，您将不得不应用某种“释放”策略。在简单的情况下，简单的时间到期将解决此问题。如果给定用户尝试在已经有锁的行上获取“锁”，您的应用程序将检查时间戳。如果时间戳过期，新用户将覆盖锁。如果没有，该行不可用。

还有其他更复杂的场景。如果在您的过程中，在操作完全完成之前，数据库中的信息发生了变化（假设用户进行了各种信息更改，并在用户完成操作并“释放”行之前将它们发送到数据库），那么您可能必须弄清楚如何实现回滚。也许让数据“半操作”是可以的，也许不是，这取决于您的业务需求。

长话短说：

> < li >锁由数据库表中的列组成 < li>

您的代码控制锁

用户尝试获取锁

仔细考虑这些建议是否适用于您的场景。

我希望这有帮助。