수정,삭제 쿼리 직접 작성 시 주의해야 할 점

1. 상황

기존의 view 증가 코드에서는 dirty checking를 사용하여 view를 update하는 쿼리가 자동으로 발생하도록 코드를 작성했다. 이 경우 view가 증가하면 @EnableAuditing으로 인해 updated도 같이 변경된다는 문제가 있다.

해당 문제의 해결을 위해 JPQL을 활용하여 영속성 컨텍스트(1차 캐시)를 무시하고 다이렉트로 DB에 수정 쿼리를 날리도록 했다. 이렇게 하면 쿼리가 실행될 때 JPA는 해당 엔티티의 상태를 감지하지 않으므로, Auditing 기능이 작동하지 않는다.

현재 상황은 단건 수정이지만, 여러개의 레코드를 수정 및 삭제할 때도 이와 유사하게 JPQL, QueryDSL 등을 활용하고 이를 "벌크 연산"이라고 한다. 

@Entity
@Getter
@Table(name = "inventories")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Inventory extends BaseEntity {
    ...

    @Column(nullable = false)
    private Integer view;
    
    public void increaseView(){
    	this.view += 1;
    }

}

@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public abstract class BaseEntity {
    @CreatedDate
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;

}

@Query에 벌크 연산을 작성한 뒤, @Modifying을 작성하지 않으면 InvalidDataAccessApiUsageException이 발생하는 것을 잊지 말자!

// 수정 전 : dirty checking을 활용하여 view를 수정한다.
public void increaseInventoryView(Long inventoryId) {
      Inventory inventory = inventoryRepository.findById(inventoryId)
            .orElseThrow(() -> new CustomException(InventoryErrorCode.INVENTORY_NOT_FOUND));
      inventory.increaseView();  // dirty checking
}

// 수정 후 : 직접 쿼리를 작성했다.
@Modifying(flushAutomatically = true, clearAutomatically = true)
@Query("update Inventory i set i.view = i.view+1 where i.id = :id")
void increaseView(@Param("id") Long id);

 

2. 주의 해야 할 점 

JPA의 영속성 컨텍스트 1차 캐시는 @Id 값을 Key 값으로 엔티티를 관리한다. 그래서 엔티티를 조회할 때 @Id 값이 1차 캐시에 존재하면 DB에 접근하지 않고, 캐싱된 엔티티를 반환한다.

1차 캐시와 DB 상태가 다를 때 발생할 수 있는 상황은 다음과 같다. 

1. 트랜잭션 시작
2. 나이가 40살인 직원들을 조회한다.
3. 나이가 40살인 직원들의 월급을 100만원 인상하고, 벌크 연산을 실행한다. 
4. findByAge(int age)로 나이가 40살인 직원들을 조회한다. (인상된 월급이 아닌, 기존 월급이 조회된다..!)
5. 트랜잭션 종료

4번에 문제가 발생하는 이유는 JPA에 1차 캐시에 해당 엔티티가 존재하면 DB 데이터가 아닌, 캐싱된 엔티티를 반환하기 때문이다.

 

해결방법 

1. 수정, 삭제가 완료되면 바로 트랜잭션을 종료한다. 즉, 수정&삭제 후 읽기를 아예 하지 않는다. 
2. flushAutomatically = true, clearAutomatically = true
   • flushAutomatically = true: JPQL 실행 이전에 flush (해당 jpql 과 관계없는 엔티티 변경상황이 clear 에 의해 지워질 수 있기 때문에)
     • flush : 영속성 컨텍스트의 변경 사항을 데이터베이스에 반영한다. 영속성 컨텍스트가 초기화 된것은 아니다. 변경된 엔티티는 여전히 영속성 컨텍스트에 남아 있으며, 이후에도 계속해서 사용할 수 있다. 
   • clearAutomatically = true: JPQL 실행 후 clear
     • clear : 영속성 컨텍스트를 비운다. clear된 엔티티는 메모리에서 제거되며, 다시 사용할 경우 데이터베이스에서 새로 로드해야한다.

물론 본인이 문제 상황을 잘 숙지하면 문제는 없지만, 여러 사람이 공유하는 코드이고 휴먼에러는 언제든 발생할 수 있기 때문에 미리 방지하는 게 좋다.

@Modifying(flushAutomatically = true, clearAutomatically = true)
@Query("update Inventory i set i.view = i.view+1 where i.id = :id")
void increaseView(@Param("id") Long id);

 

+ 테스트 코드 작성 시 발생한 문제 

@Test
@DisplayName("updatedAt는 변경 없이 이전과 동일하다.")
void it_remains_same_updatedAt() {
    inventoryRepository.increaseView(inventory.getId());
    em.flush();
    em.clear();

    Inventory updatedInventory = inventoryRepository.findById(inventory.getId())
            .orElse(null);

    assertThat(updatedInventory).isNotNull();
    assertThat(updatedInventory.getUpdatedAt()).isEqualTo(inventory.getUpdatedAt());
}

재고현황의 조회수가 증가해도 updatedAt은 변하지 않음을 확인하는 unit test를 작성한 후, PR을 올렸는데 빌드가 깨지는 일이 발생했다. ./gradlew clean build라는 동일한 명령어로 실행했는데 왜 intelliJ에서는 성공하고, github actions에서는 실패할까?

 

로그로 확인해 보는 것이 가장 정확하기에 github actions의 빌드가 깨지면 test-report를 생성하도록 했다. 

// github actions를 관리하는 yml 파일에 "Test Report 제작" task를 추가했다.

- name: Gradle 빌드
   run: ./gradlew clean build

- name: Test Report 제작
   uses: actions/upload-artifact@v3
   if: failure()
   with:
      name: test-report
      path: ./yellobook-domain/build/reports/tests/test/

 

그 결과는!

그렇다... 반올림 때문이었다... intelliJ는 반올림을 하지 않고 값 비교를 해서 test가 성공했지만, github actions에서는 소수점 아래 6자리까지 반올림을 했기에 값이 달라서 test가 실패했다.

따라서 아래와 같이 초 단위로 잘라서 값을 비교하도록 수정했다.

assertThat(updatedInventory.getUpdatedAt()
        .truncatedTo(ChronoUnit.SECONDS))
        .isEqualTo(oldUpdatedAt.truncatedTo(ChronoUnit.SECONDS));

 

참고 

https://frogand.tistory.com/174
https://velog.io/@sdsd0908/JPA-%EB%B2%8C%ED%81%AC-%EC%BF%BC%EB%A6%AC%EC%97%B0%EC%82%B0-%EC%82%AC%EC%9A%A9%EB%B2%95-em.flush