[每日短篇] 19 - Spring Data JPA 的 @Modifying 注解须要注意的问题

JPA 的 Repository 提供一种很是易用的机制用于 ORM 方式处理数据，可是若是须要一次性更新一批数据的部分字段，构造全部实体并逐个修改字段再存回数据库就显得有些臃肿。在 JPA 中提供了 @Query 注解用于使用 JPQL 执行数据库操做，若是数据库操做是修改数据而非查询数据，则须要再额外使用 @Modifying 注解提示 JPA 该操做是修改操做。

当进行 find 操做时，JPA 在 EntityManager 中缓存了 find 生成的对象，当再次 find 时会直接返回该对象。因而可能会出现下面这种状况 用 @Query 定义一个修改状态的方法

public interface EntityRepository extends JpaRepository<Entity, Integer> {

    @Modifying
    @Query("update Entity set status = 'IGNORED' where id = ?1")
    int updateStatus(int id);

}

先读取一个对象，再修改对象状态，再次读取对象

Optional<Entity> entityBefore = repository.findById(1);

repository.updateStatus(1);

Optional<Entity> entityAfter = repository.findById(1);

结果会发现 entityBefore 和 entityAfter 中的 Entity 对象 id 是相同的，中间对状态的修改并无体现出来！固然，其缘由也很明确，@Query 跟 find 和 save 系列方法是两套不一样的体系，@Query 引发的数据库变动 EntityManager 并不能发现，更进一步说，使用其它工具或者其它框架修改数据库中的数据，也不能及时反应到 JPA 的 find 系列方法上来。

固然，只要有缓存机制就必定不可避免存在此类问题，这仅是个取舍问题而不要认为是 BUG。若是要解决 find 获得的值不是数据库中最新值的问题能够有几种方式，避免使用 @Query 是一种方式，在须要时显式清理 EntityManager 的缓存也是一种方式。Spring Data JPA 提供了另一种方式则是 @Modifying(clearAutomatically = true)，@Modifying 的 clearAutomatically 属性为 true 时，执行完 modifying query 以后就会清理缓存，从而在下次 find 时就能够读取到数据库中的最新值。

自动清理以后还会带来一个新的问题，clear 操做清理的缓存中，还包括提交后未 flush 的数据，例如调用 save 而不是 saveAndFlush 就有可能不会当即将修改内容更新到数据库中，在 save 以后 flush 以前调用 @Modifying(clearAutomatically = true) 修饰的方法就有可能致使修改丢失。若是再要解决这个问题，还能够再加上另一个属性 @Modifying(clearAutomatically = true, flushAutomatically = true)，@Modifying 的 flushAutomatically 属性为 true 时，执行 modifying query 以前会先调用 flush 操做，从而避免数据丢失问题。

在实际运行中，clear 和 flush 操做均可能须要消耗必定的时间，要根据系统实际状况能够选择使用其中的一个或两个属性，以保证系统的正确性。

参考: flushAutomatically 属性是在 https://jira.spring.io/browse/DATAJPA-806 提出并被采纳的。