JPA使用@Modifying踩坑记录

JPA使用@Modifying踩坑记录

一、问题现象

开发过程中使用@Query和@Modifying批量删除数据失败，造成线上服务异常

二、问题排查

通过查看日志发现，执行批量删除出现错误日志：

HHH000346: Error during managed flush [Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) 

发现数据已被其他事务修改或删除，发现对数据修改的操作只有使用@Query和@Modifying注解的方法，所以并不存在其他事务修改或删除数据。

通过阅读代码，发现业务方法使用JpaRepository的查询方法并引入了事务，怀疑与JPA缓存机制有关。

于是在批量删除前通过调用JpaRepository.flush()方法刷新缓存，但是并没有起作用，同样报如上的异常日志。

此时，有两种情况：

1、JpaRepository.flush()没有起作用

2、不是JPA缓存机制问题

针对这两种设想进行逐一排查。

三、问题原因

      

在 JPA 中提供了 @Query 注解用于使用 JPQL 执行数据库操作，如果数据库操作是修改数据而非查询数据，则需要再额外使用 @Modifying 注解提示 JPA 该操作是修改操作。

通过查阅资料，当进行 find 操作时，JPA 在 EntityManager 中缓存了 find 生成的对象，而@Query 跟 find 和 save 系列方法是两套不同的体系，@Query 引起的数据库变更 EntityManager 并不能发现，更进一步说，使用其它工具或者其它框架修改数据库中的数据，也不能及时反应到 JPA 的 find 系列方法上来。

四、解决方案

上述问题引起的异常现象是因为缓存机制不可避免出现的问题，此时需要对此做取舍，一是避免使用@Query并显示清理EntityManager中的缓存，二是Spring Data JPA 提供了另外一种方式则是 @Modifying(clearAutomatically = true)，@Modifying 的 clearAutomatically 属性为 true 时，执行完 modifying query 之后就会清理缓存。

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

 

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

此时业务场景中只需要删除数据即可，并不会有其他修改，所以选择clearAutomatically = true即可。