[JPA & Hibernate] Spring Data JPA @Modifying

✔ 깃허브 소스코드
✔ Udemy 강의영상

🚀 @Modifying

@Modifying 어노테이션은 @Query 어노테이션으로 작성된 수정, 삭제 쿼리 메소드를 사용할 때 필요합니다. 즉, 조회 쿼리를 제외하고 데이터에 변경이 일어나는 INSERT, UPDATE, DELETE 쿼리에서 사용합니다. 주로 벌크 연산 시 사용합니다.

✔ clearAutomatically

이 속성은 @Modifying 어노테이션이 붙은 쿼리 메소드 실행 직후, 영속성 컨텍스트를 Clear 할 것인지를 지정하는 속성입니다. 디폴트 값은 false 입니다. 그러나 false 를 그대로 사용할 경우 영속성 컨텍스트의 1차 캐시와 관련된 문제가 발생할 수 있습니다.

✔ 문제점

JPA 에서는 영속성 컨텍스트에 있는 1차 캐시를 통해 엔티티를 캐싱하고, 데이터베이스의 접근 횟수를 줄여줌으로써 성능 개선을 자동으로 해줍니다. 1차 캐시는 @Id 값을 키값으로 엔티티를 관리합니다. 그래서 findById 등을 통해서 엔티티를 조회했을 시 ID 값이 1차 캐시에 존재한다면 데이터베이스에 접근하지 않고 캐싱된 엔티티를 반환합니다.

그렇다면 벌크 연산을 통해 데이터 변경 쿼리를 실행하고, 해당 엔티티를 조회하면 어떤 일이 발생할까요? 테스트 시나리오는 다음과 같습니다.

1. 엔티티 객체를 하나 생성합니다 - Transient 상태
2. save()를 통해 생성한 엔티티를 저장합니다 - Persistent 상태
3. 벌크 연산을 통해 기존의 데이터를 변경합니다 - SQL 실행
   • 💨 이때 Flush 가 발생하여 해당 쿼리 메소드가 실행 되기 전의 쿼리들은 모두 Flush 됩니다.
4. findById() 를 통해 업데이트한 엔티티를 조회합니다.

✔ 테스트 1. @Modify

엔티티 생성

@Entity
public class Course {
    
    @Id
    @GeneratedValue
    private Long id;
    
    private String name;
    ...
    
    private Course(String name) {
        this.name = name;
    }
    
    public static Course of(String name) {
        return new Course(name);
    }
}

Repository 생성

@Repository
public interface CourseRepository extends JpaRepository<Course, Long> {
    ...
    
    @Modifying
    @Query(value = "UPDATE Course C SET C.name = ?2 WHERE C.id = ?1"
    int updateById(Long id, String name);
}

테스트 코드 작성

@Test
@Transactional
public void modifyingTest() {
    Course course = Course.of("before");
    courseRepository.save(course);

    int result = courseRepository.updateById(1L, "after");
    assertEquals(result, 1);

    LOGGER.info(String.format("Updated Course Name -> {%s}", courseRepository.findById(1L).get().getName()));
}

실행 결과

결과를 보시면 INSERT, 그리고 UPDATE 모두 성공적으로 실행한 것을 볼 수가 있습니다. 그리고 해당 테스트를 실행하면 데이터베이스에서도 업데이트가 성공적으로 반영됩니다. 마지막에 엔티티를 조회할 때 현재 1차 캐시에 캐싱이 되었으므로 데이터베이스에 쿼리를 실행하지 않고 1차 캐시에에서 가져오게 됩니다. 그래서 마지막 로그를 보면 업데이트되지 않은 값을 가져오는 것을 볼 수가 있습니다.

✔ 테스트 2. @Modify(clearAutomatically = true)

다음으로는 clearAutomatically = true 속성을 추가하고 테스트를 실행합니다.

@Modifying
@Query(value = "UPDATE Course C SET C.name = ?2 WHERE C.id = ?1"
int updateById(Long id, String name);

결과를 보시면 지금은 조회를 할 때 데이터베이스에 쿼리를 실행하게 되고 업데이트된 값을 가져오는 것을 볼 수가 있습니다.

🎯 결론

JPA 의 1차 캐시는 데이터베이스의 접근 횟수를 줄여서 성능 개선을 할 수 있는 좋은 기능이지만, @Modifying 과 @Query 를 사용한 벌크 연산에서는 이 기능 때문에 예측하지 못한 결과가 나올 수 있습니다. 그 원인은 다음과 같습니다.

JPA 에서 조회를 실핼할 시에 1차 캐시를 확인해서 해당 엔티티가 1차 캐시에 존재한다면 데이터베이스에 접근하지 않고, 1차 캐시에 있는 엔티티를 반환합니다. 하지만 벌크 연산은 1차 캐시를 포함한 영속성 컨텍스트를 무시하고 바로 쿼리를 실행하기 때문에 영속석 컨텍스트는 데이터 변경을 알 수가 없습니다. 즉, 벌크 연산 실행 시 1차 캐시와 데이터베이스의 싱크가 일치하지 않게 되는 것입니다.

그래서 @Modifying의 clearAutomatically = true를 설정해주면 이 문제를 해결할 수 있습니다. 벌크 연산 직후 자동으로 영속성 컨텍스트를 Clear 해줍니다. 그래서 조회를 실행하면 1차 캐시에 해당 엔티티가 존재하지 않기 때문에 데이터베이스로 쿼리를 실행하게 됩니다.

📑 Reference

• https://devhyogeon.tistory.com/4