[每日短篇] 19 - Spring Data JPA 的 @Modifying 注解需要注意的问题
JPA 的 Repository 提供一种非常易用的机制用于 ORM 方式处理数据，但是如果需要一次性更新一批数据的部分字段，构造所有实体并逐个修改字段再存回数据库就显得有些臃肿。在 JPA 中提供了 @Query 注解用于使用 JPQL 执行数据库操作，如果数据库操作是修改数据而非查询数据，则需要再额外使用 @Modifying 注解提示 JPA 该操作是修改操作。
当进行 find 操作时，JPA 在 EntityManager 中缓存了 find 生成的对象，当再次 find 时会直接返回该对象。于是可能会出现下面这种情况 用 @Query 定义一个修改状态的方法
public interface EntityRepository extends JpaRepository {
@Modifying
@Query("update Entity set status = 'IGNORED' where id = ?1")
intupdateStatus(intid);
}
先读取一个对象，再修改对象状态，再次读取对象
Optional entityBefore = repository.findById(1);
repository.updateStatus(1);
Optional 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 提出并被采纳的。
