使用 JPA / Hibernate 在无状态应用程序中进行乐观锁定

Question

我想知道在无法在请求之间保留具有特定版本的实体实例的系统中实现乐观锁定（乐观并发控制）的最佳方法是什么。这实际上是一个非常常见的场景，但几乎所有示例都基于将在请求之间（在 http 会话中）保存已加载实体的应用程序。

如何在 API 污染尽可能少的情况下实现乐观锁定？

约束

• 该系统是根据领域驱动设计原则开发的。
• 客户端/服务器系统
• 实体实例不能在请求之间保留（出于可用性和可扩展性的原因）。
• 技术细节应尽可能少地污染域的 API。

堆栈是带有 JPA (Hibernate) 的 Spring，如果这应该有任何相关性的话。

仅使用@Version 时出现问题

在许多文档中，您似乎只需用@Version 装饰字段，JPA/Hibernate 会自动检查版本。但这只有在加载的对象及其当前版本保存在内存中直到更新更改同一个实例时才有效。

在无状态应用程序中使用@Version 会发生什么：

1. 客户端 A 使用 id = 1 加载项目并获取 Item(id = 1, version = 1, name = "a")
2. 客户端 B 使用 id = 1 加载项目并获取 Item(id = 1, version = 1, name = "a")
3. 客户端 A 修改项目并将其发送回服务器：Item(id = 1, version = 1, name = "b")
4. 服务器使用返回Item(id = 1, version = 1, name = "a")的EntityManager加载项目，它更改name并保持Item(id = 1, version = 1, name = "b")。 Hibernate 将版本增加到2。
5. 客户端 B 修改项目并将其发送回服务器：Item(id = 1, version = 1, name = "c")。
6. 服务器用返回Item(id = 1, version = 2, name = "b")的EntityManager加载项目，它改变name并保持Item(id = 1, version = 2, name = "c")。 Hibernate 将版本增加到3。 似乎没有冲突！

正如您在第 6 步中看到的，问题在于 EntityManager 在更新之前立即重新加载项目的当前版本 (version = 2)。 Client B 使用version = 1 开始编辑的信息丢失，Hibernate 无法检测到冲突。客户端 B 执行的更新请求必须保持 Item(id = 1, version = 1, name = "b")（而不是 version = 2）。

JPA/Hibernate 提供的自动版本检查仅在初始 GET 请求上加载的实例在服务器上的某种客户端会话中保持活动状态时才有效，并且稍后将由相应的客户端更新。但在无状态服务器中，必须以某种方式考虑来自客户端的版本。

可能的解决方案

显式版本检查

可以在应用服务的方法中执行显式版本检查：

@Transactional
fun changeName(dto: ItemDto) {
    val item = itemRepository.findById(dto.id)
    if (dto.version > item.version) {
        throw OptimisticLockException()
    }
    item.changeName(dto.name)
}

优点

• 域类 (Item) 不需要从外部操作版本的方法。
• 版本检查不是域的一部分（版本属性本身除外）

缺点

• 容易忘记
• 版本字段必须是公开的
• 不使用框架的自动版本检查（在可能的最迟时间点）

可以通过额外的包装来防止忘记检查（在下面的示例中为ConcurrencyGuard）。存储库不会直接返回项目，而是会执行检查的容器。​​

@Transactional
fun changeName(dto: ItemDto) {
    val guardedItem: ConcurrencyGuard<Item> = itemRepository.findById(dto.id)
    val item = guardedItem.checkVersionAndReturnEntity(dto.version)
    item.changeName(dto.name)
}

缺点是在某些情况下检查是不必要的（只读访问）。但可能还有另一种方法returnEntityForReadOnlyAccess。另一个缺点是ConcurrencyGuard 类会给存储库的域概念带来技术方面的影响。

按 ID 和版本加载

实体可以通过ID和版本加载，这样冲突就会在加载时显示出来。

@Transactional
fun changeName(dto: ItemDto) {
    val item = itemRepository.findByIdAndVersion(dto.id, dto.version)
    item.changeName(dto.name)
}

如果 findByIdAndVersion 会找到具有给定 ID 但版本不同的实例，则会抛出 OptimisticLockException。

优点

• 不可能忘记处理版本
• version 不会污染域对象的所有方法（尽管存储库也是域对象）

缺点

• 存储库 API 的污染
• findById 初始加载（开始编辑时）无论如何都需要没有版本，并且这种方法很容易被意外使用

使用显式版本更新

@Transactional
fun changeName(dto: itemDto) {
    val item = itemRepository.findById(dto.id)
    item.changeName(dto.name)
    itemRepository.update(item, dto.version)
}

优点

• 并非实体的每个变异方法都必须使用版本参数污染

缺点

• Repository API 被技术参数version 污染
• 显式 update 方法会与“工作单元”模式相矛盾

在突变时显式更新版本属性

版本参数可以传递给可以在内部更新版本字段的变异方法。

@Entity
class Item(var name: String) {
    @Version
    private version: Int

    fun changeName(name: String, version: Int) {
        this.version = version
        this.name = name
    }
}

优点

• 不可能忘记

缺点

• 所有变异域方法中的技术细节泄漏
• 容易忘记
• 直接更改托管实体的版本属性为not allowed。

这种模式的一种变体是直接在加载的对象上设置版本。

@Transactional
fun changeName(dto: ItemDto) {
    val item = itemRepository.findById(dto.id)
    it.version = dto.version
    item.changeName(dto.name)
}

但这会直接暴露版本以供读写，并且会增加出错的可能性，因为这个调用很容易被忘记。但是，并不是每个方法都会被version 参数污染。

创建一个具有相同 ID 的新对象

可以在应用程序中创建与要更新的对象具有相同 ID 的新对象。该对象将在构造函数中获取版本属性。然后将新创建的对象合并到持久化上下文中。

@Transactional
fun update(dto: ItemDto) {
    val item = Item(dto.id, dto.version, dto.name) // and other properties ...
    repository.save(item)
}

优点

• 一致的各种修改
• 不可能忘记版本属性
• 不可变对象很容易创建
• 很多情况下不需要先加载现有对象

缺点

• ID 和版本作为技术属性是领域类接口的一部分
• 创建新对象会阻止使用在域中有意义的变异方法。也许有一个changeName 方法应该只对更改而不是对名称的初始设置执行特定操作。在这种情况下不会调用这样的方法。也许这个缺点可以通过特定的工厂方法来缓解。
• 与“工作单元”模式冲突。

问题

您将如何解决它，为什么？有更好的主意吗？

相关

• Optimistic locking in a RESTful application
• Managing concurrency in a distributed RESTful environment with Spring Boot and Angular 2（这基本上是上面使用 HTTP 标头实现的“显式版本检查”）

Answer 1

这里的所有解释和建议都很有帮助，但由于最终的解决方案有点不同，我认为值得分享。

直接操作version 不能正常工作并且与JPA 规范冲突，所以没有选择。

最终的解决方案是JPA Hibernate的显式版本检查+自动版本检查。在应用层执行显式版本检查：

@Transactional
fun changeName(dto: ItemDto) {
    val item = itemRepository.findById(dto.id)
    rejectConcurrentModification(dto, item)
    item.changeName(dto.name)
}

为减少重复，实际检查以单独的方法进行：

fun rejectConcurrentModification(dto: Versioned, entity: Versioned) {
    if (dto.version != entity.version) {
        throw ConcurrentModificationException(
            "Client providing version ${dto.version} tried to change " + 
            "entity with version ${entity.version}.")
    }
}

实体和 DTO 都实现了Versioned 接口：

interface Versioned {
    val version: Int
}

@Entity
class Item : Versioned {
    @Version
    override val version: Int = 0
}

data class ItemDto(override val version: Int) : Versioned

但是从两者中拉出version 并将其传递给rejectConcurrentModification 也同样有效：

rejectConcurrentModification(dto.version, item.verion)

应用层显式检查的明显缺点是它可能被遗忘。但是由于存储库必须提供一种方法来加载没有版本的实体，因此将版本添加到存储库的find 方法也不安全。

在应用层显式版本检查的好处是它不会污染域层，除非version 需要从外部读取（通过实现Versioned 接口）。实体或存储库方法都是域的一部分，不会被version 参数污染。

没有在最晚的可能时间点执行显式版本检查并不重要。如果在此检查和数据库的最终更新之间，另一个用户会修改同一个实体，那么 Hibernate 的自动版本检查将生效，因为在更新请求开始时加载的版本仍在内存中（在我的示例中的 changeName 方法）。因此，第一次显式检查将防止在客户端编辑开始和显式版本检查之间发生并发修改。并且自动版本检查会阻止显式检查和数据库最终更新之间的并发修改。

Answer 2

为了防止并发修改，我们必须在某处跟踪正在修改的项目版本。

如果应用程序是有状态的，我们可以选择将此信息保留在服务器端，可能在会话中，尽管这可能不是最佳选择。

在无状态应用程序中，此信息必须一直传递到客户端并随每个变异请求返回。

因此，IMO，如果防止并发修改是一项功能要求，那么在变异 API 调用中包含项目版本信息不会污染 API，它会使其完整。

Answer 3

当您从数据库加载记录以处理更新请求时，您必须将该加载的实例配置为具有客户端提供的相同版本。但不幸的是，当一个实体被管理时，它的版本 cannot be changed manually 是 JPA 规范所要求的。

我尝试跟踪 Hibernate 源代码，但没有注意到任何 Hibernate 特定功能可以绕过此限制。值得庆幸的是，版本检查逻辑很简单，我们可以自己检查。返回的实体仍然是托管的，这意味着工作单元模式仍然可以应用于它：

// the version in the input parameter is the version supplied from the client
public Item findById(Integer itemId, Integer version){
    Item item = entityManager.find(Item.class, itemId);

    if(!item.getVersoin().equals(version)){
      throws  new OptimisticLockException();
    }
    return item;
}

---

由于担心 API 会被version 参数污染，我将entityId 和version 建模为一个域概念，由一个名为EntityIdentifier 的值对象表示：

public class EntityIdentifier {
    private Integer id;
    private Integer version;
}

然后有一个BaseRepository 通过EntityIdentifier 加载一个实体。如果EntityIdentifier 中的version 为NULL，则将其视为最新版本。其他实体的所有存储库都将对其进行扩展以重用此方法：

public abstract class BaseRepository<T extends Entity> {

    private EntityManager entityManager;

    public T findById(EntityIdentifier identifier){

         T t = entityManager.find(getEntityClass(), identifier.getId());    

        if(identifier.getVersion() != null && !t.getVersion().equals(identifier.getVersion())){
            throws new OptimisticLockException();
        }
        return t;
 } 

注意：此方法并不意味着在确切的版本中加载实体的状态，因为我们在这里不进行事件溯源，也不会在每个版本中存储实体状态。加载实体的状态总是最新版本，EntityIdentifier 中的版本仅用于处理乐观锁定。

为了使其更通用和更易于使用，我还将定义一个EntityBackable 接口，以便BaseRepository 在实现后可以加载任何支持的实体（例如DTO）。

public interface EntityBackable{
    public EntityIdentifier getBackedEntityIdentifier();
}

并将以下方法添加到BaseRepository：

 public T findById(EntityBackable eb){
     return findById(eb.getBackedEntityIdentifier());
 }

所以最后，ItemDto 和 updateItem() 应用服务看起来像：

public class ItemDto implements EntityBackable {

    private Integer id;
    private Integer version;

    @Override
    public EntityIdentifier getBackedEntityIdentifier(){
         return new EntityIdentifier(id ,version);
    }
}

@Transactional
public void changeName(ItemDto dto){
    Item item = itemRepository.findById(dto);
    item.changeName(dto.getName());
}

总而言之，这个解决方案可以：

• 工作单元模式仍然有效
• 存储库 API 不会填充版本参数
• 所有关于版本控制的技术细节都封装在BaseRepository中，所以没有技术细节泄露到域中。

---

注意：

• setVersion() 仍然需要从域实体中公开。但我可以接受，因为从存储库获取的实体是受管理的，这意味着即使开发人员调用 setVersion() 也不会影响实体。如果您真的不希望开发人员致电setVersion()。您可以简单地添加一个ArchUnit test 来验证它只能从BaseRepository 调用。

Answer 4

服务器使用返回 Item(id = 1, version = 1, name = "a") 的 EntityManager 加载项目，它更改名称并保留 Item(id = 1, version = 1, name = "b ”）。 Hibernate 将版本增加到 2。

这是对 JPA API 的滥用，也是您的错误的根本原因。

如果您改用entityManager.merge(itemFromClient)，则会自动检查乐观锁定版本，并拒绝“过去的更新”。

需要注意的是entityManager.merge 将合并实体的整个状态。如果您只想更新某些字段，那么简单的 JPA 会有些混乱。具体是因为you may not assign the version property，所以必须自己查版本。但是，该代码很容易重用：

<E extends BaseEntity> E find(E clientEntity) {
    E entity = entityManager.find(clientEntity.getClass(), clientEntity.getId());
    if (entity.getVersion() != clientEntity.getVersion()) {
        throw new ObjectOptimisticLockingFailureException(...);
    }
    return entity;
}

然后你可以简单地做：

public Item updateItem(Item itemFromClient) {
    Item item = find(itemFromClient);
    item.setName(itemFromClient.getName());
    return item;
}

根据不可修改字段的性质，您也可以这样做：

public Item updateItem(Item itemFromClient) {
    Item item = entityManager.merge(itemFromClient);
    item.setLastUpdated(now());
}

对于以 DDD 方式执行此操作，版本检查是持久性技术的一个实现细节，因此应该发生在存储库实现中。

为了通过应用程序的各个层传递版本，我发现将版本作为域实体或值对象的一部分很方便。这样，其他层就不必显式地与版本字段交互。