변경감지(더티체킹) 이후 플러시할 경우의 쿼리

gsjh2001

投稿した質問数 1

0

안녕하세요, 인프런 AI 인턴입니다.

JPA의 변경 감지 메커니즘과 관련된 질문을 주셨습니다. 우선 JPA의 영속성과 관련 이해를 돕기 위해 좀 더 자세히 설명드리겠습니다.

변경 감지 플로우

1. persist() 메서드를 호출하면 엔티티는 1차 캐시에 저장되고, 쓰기 지연 SQL 저장소에 INSERT 쿼리가 저장됩니다. 이 시점에는 데이터베이스에 즉시 반영되지 않습니다.

2. 이후 setName() 메서드를 사용하여 엔티티의 값을 변경하게 되면, 여전히 영속성 컨텍스트 안에서 관리되고 있으며, 스냅샷은 여전히 초기에 ‘persist()’ 했을 때의 상태로 남아 있습니다.

3. flush() 를 호출하면 JPA는 스냅샷과 현재 상태를 비교하여 변경 사항이 있을 경우 이를 반영합니다. 이때, 변경이 감지되면 UPDATE 쿼리를 생성할 수 있는데, 여기서 오해가 발생할 수 있습니다.

왜 INSERT만 나가는가?

• persist() 이후 flush() 시점 이전의 setXXX() 같은 메서드 호출은 엔티티의 상태를 바꾸지만, 여전히 영속성 컨텍스트 내에서는 초기 상태로 스냅샷을 보존합니다. 최종적으로 flush() 할 때는 다음을 수행하게 됩니다:

  1. INSERT 시점에서는 이미 변경된 상태의 값을 고려하여 새로운 값으로만 INSERT됩니다.
     
  2. 아직 DB에 반영되지 않은 상태이므로 UPDATE 가 필요하지 않은 것입니다. 즉, 처음에 INSERT할 때, 이미 변경된 업데이트된 상태의 데이터를 DB로 보낸다고 보면 됩니다.
     

• 첫 번째 flush 시점에서는 INSERT로 최종적으로 데이터베이스에 반영되므로 UPDATE 쿼리는 불필요해집니다.

이와 관련된 JPA의 flush 및 쓰기 지연은 많은 개발자들이 JPA 변경 감지(Dirty Checking) 관점에서 헷갈려 하는 부분인데, 초기 값을 반영하기 위한 INSERT 이후의 상태 변화를 감시하기 때문에 INSERT 만 수행하고 유효하게 적용할 수 있습니다.

아래 관련 게시글을 참고하셔서 추가적인 내용을 읽어보시면 이해에 도움이 될 수 있습니다:
- 1차캐시와 SQL 쓰기지연 저장소에 저장되는 시점이 궁금합니다.
- 변경 감지가 일어나는 시점에 대하여 궁금한 점이 있습니다.

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