JPA / Hibernate：基于版本的乐观并发控制

本文是Hibernate和JPA中基于版本的乐观并发控制的简介。这个概念已经很老了，上面已经写了很多东西，但是无论如何我都看到了它被重新发明，误解和滥用。我在编写它只是为了传播知识，并希望引起人们对并发控制和锁定的兴趣。

用例

假设我们有一个供多个用户使用的系统，其中每个实体可以由多个用户修改。我们希望避免两个人加载一些信息，根据他们看到的内容做出一些决定并同时更新状态的情况。我们不希望丢失在第一个交易中首先单击“保存”的用户通过覆盖它们所做的更改。

它也可能在服务器环境中发生–多个事务可以修改共享实体，我们希望避免出现以下情况：

交易1载入资料
事务2更新该数据并提交
使用在步骤1中加载的状态（不再是当前状态），事务1执行一些计算并更新状态

在某些方面，它与不可重复的读取具有可比性。

解决方案：版本控制

因此，Hibernate和JPA实现了基于版本的并发控制的概念。运作方式如下。

您可以使用@Version或<version> （数字或时间戳）标记一个简单的属性。这将是数据库中的特殊列。我们的映射如下所示：

@Entity
@Table(name = 'orders')
public class Order {@Idprivate long id;@Versionprivate int version;private String description;private String status;// ... mutators
}

当这样的实体持续存在时，version属性将设置为起始值。

每当更新时，Hibernate都会执行如下查询：

update orders
set description=?, status=?, version=?
where id=? and version=?

请注意，在最后一行， WHERE子句现在包括version 。此值始终设置为“旧”值，因此只有在具有预期版本的情况下，它才会更新行。

假设有两个用户在版本1中加载订单，并花一些时间在GUI中查看订单。

安妮决定批准该订单并执行该操作。数据库中的状态已更新，一切正常。传递给update语句的版本如下：

update orders
set description=?, status=?, version=2
where id=? and version=1

如您所见，在持久化更新持久层时，版本计数器将增加到2。

在她的GUI中，Betty仍然具有旧版本（编号1）。当她决定对订单执行更新时，该语句如下所示：

update orders
set description=?, status=?, version=2
where id=? and version=1

此时，在Anne的更新之后，数据库中该行的版本为2。因此，第二次更新影响0行（没有与WHERE子句匹配的行）。 Hibernate会检测到它，并检测到一个org.hibernate.StaleObjectStateException （包装在javax.persistence.OptimisticLockException ）。

结果，第二个用户除非刷新视图，否则无法执行任何更新。为了获得适当的用户体验，我们需要进行一些干净的异常处理，但是我将省略。

组态

这里几乎没有要自定义的内容。 @Version属性可以是数字或时间戳。数字是人为的，但通常在内存和数据库中占用较少的字节。时间戳较大，但始终会更新为“当前时间戳”，因此您可以实际使用它来确定实体的更新时间。

为什么？

那为什么要使用它呢？