엔티티 수정 과정과 쓰기 지연 저장소

안녕하세요. 김지호님

다음 순서로 이해하시면 됩니다 🙂

1. member.setUsername(",,,"); 와 같은 변경 메소드 호출

   1. member 엔티티는 영속성 컨텍스트가 관리하기 때문에 영속성 컨텍스트의 member 엔티티의 값도 함께 변경된다고 이해하면 됨

2. commit()후 flush()가 호출되며 스냅샷과 영속성 컨텍스트에 등록되어있는 엔티티 사이의 불일치 감지

3. 변경된 엔티티를 쓰기 지연 SQL 저장소에 등록

4. flush로 쓰기 지연 SQL 저장소의 쿼리를 DB에 전송

감사합니다.

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

김지호님의 질문에 대해 관련된 정보를 파악한 결과, 엔티티 수정 과정과 쓰기 지연 저장소의 작동 원리에 대한 질의에 관한 설명입니다.

1. 엔티티의 수정 과정:

   • 엔티티의 변화가 발생하면 (예: member.setUsername(",,,");) 이 변화는 즉시 영속성 컨텍스트 내에 반영됩니다. 이 때 변경 감지 (Dirty Checking) 기능이 작동하여, 트랜잭션 커밋 시점에 flush()가 호출될 때, 영속성 컨텍스트 내의 스냅샷(최초 상태)과 현재 엔티티 상태를 비교합니다.
     
   • 변경이 감지된 엔티티에 대해서는 쓰기 지연 SQL 저장소에 UPDATE 쿼리가 생성되고 등록됩니다.
     
   • flush() 호출 시, 쓰기 지연 SQL 저장소에 등록된 모든 쿼리 (INSERT, UPDATE, DELETE)가 데이터베이스로 전송되어 실행됩니다.
     

2. 쓰기 지연 저장소의 역할과 커밋 후 flush의 동작:

   • 쓰기 지연 저장소는 트랜잭션 커밋 시까지 SQL을 모아두는 버퍼 역할을 합니다. 이는 네트워크 비용을 최적화하고, 데이터 베이스 트랜잭션의 단위를 보장하는데 목적이 있습니다.
     
   • 커밋이 호출되면, 트랜잭션의 끝을 의미하며, 이때 flush()가 자동으로 호출되어 변경 감지를 수행하고, 쓰기 지연 저장소에 등록된 쿼리를 데이터베이스에 전송합니다. 따라서, 커밋 후에 새롭게 쿼리가 등록되는 것이 아니라, 기존에 변경 감지를 통해 미리 쓰기 지연 저장소에 등록된 SQL을 실행하는 것입니다.
     

김지호님의 설명대로 과정 1부터 6까지는 JPA에서 엔티티가 수정되는 일련의 과정을 정확히 설명하고 있습니다. 두 번째 질문에 대해서는, 실제로 쓰기 지연 저장소에는 SQL 문만 저장되며, “엔티티 자체”가 저장되지는 않습니다. 쓰기 지연 저장소에는 commit()이 호출될 때까지 데이터베이스에 반영될 SQL 명령문들이 누적되어 있고, flush() 시점에 데이터베이스에 전송됩니다.

관련 내용으로 세부적인 설명을 제공하는 유사 질문에 대한 답변이 있어 해당 부분에 관심이 있으시면 참조하시면 좋을 것 같습니다.

• “JPA 1차 캐시와 쓰기지연 DB 질문 드립니다.”에서는 persist와 flush 동작에 대한 설명과 함께, 쓰기 지연 저장소 동작을 설명하고 있습니다.

• “1차캐시와 SQL 쓰기지연 저장소에 저장되는 시점이 궁금합니다.”에서는 쓰기 지연 SQL 저장소에 대한 질문과, SQL 쓰기지연 저장소와 1차 캐시 사이의 상호작용에 대해 설명하고 있습니다.

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