인프런 커뮤니티 질문&답변

오랜만에 관련된 업무 진행하다가 발생한 궁금점에 대하여 질문드리게 되었습니다. 우선 한 트랜젝션의 영속성 컨텍스트에 대하여 쓰기 지연 저장소에 쌓인 쿼리가 flush() 되는 경우는 다음 세 가지로 이해하였습니다.

• flush() 직접호출

• 트랜젝션 commit()

• JPQL 직접 발생시, 해당 JPQL 발생 이전

   

다음과 같은 연관관계가 가정되어 있다고 해보겠습니다.

    public class Car{
        @Id
        private Long id;
    }
    
    public class Wheel {
        @Id
        private Long id;
        
        @ManyToOne
        @JoinColumn(name = "car_id")
        private Car car;
    }

Wheel 이 연관관계의 주인이며, Car 와 M:1 관계로 매핑되어 있습니다.

이 때, 다음과 같은 로직을 수행해보겠습니다. (1L 의 Wheel 이 2L 의 Car 에 매핑되어 있음)

Wheel wheel = em.find(Wheel.class, 1L);
wheel.setCar(null);    // 1) 

em.createQuery("delete from Car c where c.id = :id")
    .setParameter("id", 2L)
    .exeucteUpdate();    // 2)

이와 같이 수행되었을 때,

1번 시점에서 영속성 컨텍스트에 보관중인 Wheel 의 Car 값이 변경되어 Update 쿼리가 발생하여 쓰기 지연 저장소에 저장되었을 것으로 추측합니다.

2번 시점은 위에서 말한 'flush 발생시점' 중 3번에 해당한다고 생각했습니다 (JPQL 직접 수행). 그렇다면 쓰기 지연 저장소에 쌓인 Update 쿼리가 나간 이후, 직접 수행하려는 Delete JPQL 을 발생시켜서 아무 문제 없이 수행되어야 하는거 아닌가 싶었는데, 위 로직은 FK 제약조건에 위배되어 수행되지 못합니다.

1번과 2번 사이에 강제로 em.flush() 를 진행해주면, 그제서야 update 쿼리가 발생한 뒤에 delte 쿼리가 발생하여 위 로직이 아무 에러 없이 수정되는 모습을 확인했습니다.

왜 이 상황에서는 flush 가 자동으로 발생하지 않나요? 열심히 찾아봤을 때... JPA 측에서 제공하는 3번 (JPQL 발생시 flush 됨) 에 대한 명확한 [기준] 은 제시하고 있지 않은 것으로 보이는데 맞을까요??