基于Spring Data JPA构建安全条件更新REST API的方案问询

问题 #

我用Spring Data JPA（Hibernate）开发应用，对外提供REST API操作持久化数据。当客户端发起PUT/PATCH请求更新数据时，会附带实体的预期版本号。

实体类定义如下：

@Entity
public class Person {

  @Version
  @Column(name="entity_version")
  private Long version;

   // getters and setters
}

当前更新流程：

1. 从数据库查询现有实体；
2. 用person.setVersion(expectedVersionReceivedFromRestClient)设置客户端传来的预期版本；
3. 应用更新数据到实体；
4. 调用repo.save(entity)保存。

但问题是，就算客户端传错版本号，也不会触发OptimisticLockException。调试发现Hibernate在合并前会刷新实体，手动设置的版本值被覆盖，更新总是成功，不符合预期。

查文档知道不能手动设置@Version注解的属性，但不知道怎么把无状态REST场景和JPA模型结合。我研究过Spring Data REST的If-Match头方案，但它是先检查版本再更新，存在并发安全问题——两个并发请求可能同时通过检查并执行更新，导致更新丢失。

我认为安全的机制应该生成类似这样的SQL：

UPDATE persons
SET    ..., -- set column values
      entity_version = entity_version+1       
WHERE id = :id
AND   entity_version = :expected_entity_version

更新行数为1则成功，为0则返回412 Precondition Failed（这也是Hibernate处理@Version的方式，但没法直接复用）。

现在想知道：怎么基于Spring Data JPA构建安全的条件更新REST API，避免并发更新互相覆盖？

解决方案 #

方案1：正确复用JPA乐观锁机制 #

核心是不要手动修改@Version字段，让JPA自己管理版本校验和递增，流程调整为：

1. 根据ID查询数据库中的实体；
2. 先对比客户端传来的预期版本与数据库实体的版本：
   • 不一致直接返回412 Precondition Failed；
   • 一致则继续更新；
3. 将客户端的更新数据应用到实体；
4. 调用repo.save(entity)——此时Hibernate会自动生成带版本条件的UPDATE语句，若并发更新导致版本已变化，会抛出OptimisticLockException；
5. 捕获异常后返回412。

代码示例：

@Service
public class PersonService {

    @Autowired
    private PersonRepository personRepository;

    @Transactional
    public Person updatePerson(Long id, Long expectedVersion, PersonUpdateDTO updateDTO) {
        Person existingPerson = personRepository.findById(id)
                .orElseThrow(() -> new ResourceNotFoundException("Person not found"));

        // 先做版本校验
        if (!existingPerson.getVersion().equals(expectedVersion)) {
            throw new PreconditionFailedException("版本不匹配");
        }

        // 应用更新字段
        existingPerson.setName(updateDTO.getName());
        // 其他字段更新...

        try {
            return personRepository.save(existingPerson);
        } catch (OptimisticLockException e) {
            throw new PreconditionFailedException("检测到并发更新，请重试");
        }
    }
}

这里的双重保障：前置版本检查快速拦截大部分不匹配请求，而save时的乐观锁校验则保证了并发场景下的原子性，不会出现更新丢失。

方案2：自定义带版本条件的更新查询 #

如果不想查询实体再更新，可以直接在Repository中定义自定义JPQL/SQL，通过更新行数判断操作是否成功，天然保证原子性。

Repository定义：

public interface PersonRepository extends JpaRepository<Person, Long> {

    @Modifying
    @Query("UPDATE Person p SET p.name = :name, p.version = p.version + 1 WHERE p.id = :id AND p.version = :expectedVersion")
    int updatePersonWithVersionCheck(@Param("id") Long id, @Param("name") String name, @Param("expectedVersion") Long expectedVersion);
}

Service层处理：

@Transactional
public void updatePerson(Long id, Long expectedVersion, PersonUpdateDTO updateDTO) {
    int updatedRows = personRepository.updatePersonWithVersionCheck(id, updateDTO.getName(), expectedVersion);
    if (updatedRows == 0) {
        throw new PreconditionFailedException("版本不匹配或用户不存在");
    }
}

这种方式直接执行单条UPDATE语句，没有中间查询步骤，完全避免并发安全问题，适合字段较少的更新场景。

方案3：@DynamicUpdate配合乐观锁 #

如果实体字段多、不想写大量自定义查询，可以给实体加上@DynamicUpdate注解，让Hibernate只更新变化的字段，同时保留乐观锁的自动校验逻辑。

实体类修改：

@Entity
@DynamicUpdate // 仅更新有变化的字段
public class Person {

    @Version
    @Column(name="entity_version")
    private Long version;

    // 其他字段、getters/setters
}

Service层逻辑和方案1一致，不需要额外修改，Hibernate会自动生成包含版本条件、仅更新变更字段的UPDATE语句，兼顾灵活性和并发安全性。

内容的提问来源于stack exchange，提问作者peterh