remove() 정확한 흐름을 알고싶습니다

Question

위 링크 속 질문에 대한 답변을 아래와 같이 이해하였습니다.

em.remove(member)를 하는 순간에 member가 1차 캐시에서 제거되고

동시에 delete 쿼리가 쓰기 지연 SQL 저장소에 저장

commit()을 만나면 내부적으로 flush()를 호출하고 쓰기 지연 SQL 저장소에 있는 쿼리가 나간다고 이해했습니다.

그리고 아래와 같은 테스트를 했을 때 의문이 생겼습니다

Member member1 = em.find(Member.class, 101L);

em.remove(member1);
Member member2 = em.find(Member.class, 101L);

System.out.print(member2); // null

tx.commit();

위 테스트의 결과는

처음 member1을 찾을 때 select 문 1번

remove()로 인한 delete 문 1번

이처럼 총 2번 발생했습니다

하지만 제 생각은

remove()를 하면서 1차 캐시에서 지웠기 때문에

두 번째 find() 시에는 쿼리를 날려야 되는거 아닌가요?

그리고 또 이해가 안되는 부분은 member2를 찍어보면 null 이 나옵니다.

commit()을 하기 전, 즉 flush()를 통해

remove()에 의해 만들어진 쓰기 지연 SQL 저장소에 저장된

delete 문이 나가기 전인데 왜 null이 찍히는 걸까요?

정리하자면

두번째 find()는 왜 안 날라가는지
member2는 왜 null 인지

별도로 궁금한 점

쓰기 지연 SQL 저장소에 있는 쿼리들은 들어온 순서대로 나가나요?

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. 조태준님의 질문에 대한 답변을 드리겠습니다.

먼저, JPA의 영속성 컨텍스트와 쓰기 지연 기능에 대한 이해가 필요합니다.

em.remove() 동작:
- em.remove(member)를 호출하면 해당 엔티티를 1차 캐시에서 제거하고 DELETE 쿼리를 쓰기 지연 SQL 저장소에 저장합니다. 이 쿼리는 트랜잭션 커밋 시점에 flush()를 통해 실행됩니다.
두 번째 find()에서 쿼리가 발생하지 않는 이유:
- em.remove()가 호출되면, 해당 엔티티는 1차 캐시에서 완전히 제거됩니다. 따라서 101L의 엔티티는 캐시에서 사용할 수 없고, em.find()가 다시 시도하더라도 캐시나 데이터베이스에서 찾을 엔티티가 없기 때문에 null로 반환됩니다.
- 하지만, 영속성 컨텍스트가 변화되면서 불필요한 추가 쿼리를 방지하는 JPA의 최적화로 인해 실제 select 쿼리가 나가지 않음을 보여주는 사례 중 하나입니다.
member2가 null인 이유:
- 두 번째 find() 호출에서 1차 캐시가 비워져 있고, DB에도 DELETE가 플러시되어 데이터가 사라지기 전에 조회가 발생하였기 때문에 null로 반환됩니다.
쓰기 지연 SQL 저장소의 처리 순서:
- 쓰기 지연 SQL 저장소에 저장된 쿼리들은 보통 순차적으로 (작성된 순서대로) 데이터베이스에 반영됩니다. 그러나 이것은 JPA 구현체의 최적화에 따라 다를 수 있습니다. 일반적으로는 작성 순서대로 flush가 일어나지만, 하이버네이트 등과 같은 특정 ORM 프레임워크는 최적화 로직을 적용할 수도 있습니다.

추가적으로 더 깊이 이해하시려면 관련된 다른 질문들을 참조하시기 바랍니다:

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

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

remove() 정확한 흐름을 알고싶습니다