변경 감지가 일어나는 시점에 대하여 궁금한 점이 있습니다.

제가 확인을 늦게 했네요..

정말 친절한 답변 주셔서 감사드립니다. 잘 읽어보았습니다.

변경 감지를 언제 해야하는 지 자체적으로 체크하기는 효율적인 측면에서 어렵다고 생각합니다. dirty checking이라는 영어 표현과 같이, flush라는 신호를 받고 나서 영속성 컨텍스트가 스냅샷과 엔티티의 비교를 시작하는게 효율적이다.

이 부분 말씀 덕분에 깊게 이해되는 것 같습니다. 영한님께서 여러 번 말씀하시던 "용 빼는 재주가 없다." 그렇기 때문에 flush로 변경 감지 신호를 받는다. 가 맞는 논리의 순서인 것 같습니다.

또한 매번 변경 감지를 실행하면 롤백의 위험도 있고, 메모리 사용 면에서도 효율적이지 않을 것 같습니다.

감사합니다!

감사합니다.
좋은 질문 덕분에 저도 제 말로 정리할 수 있는 시간이었습니다. :)

안녕하세요, y2gcoder님!

제가 나름대로 찾아본 자료(Baeldung 사이트)에서, 다음과 같은 설명이 있었습니다.

물론 이것도 공식 문서는 아니라서, 정답인지는 모르겠지만..

Persistence context keeps track of any changes made into a managed entity. If anything changes during a transaction, then the entity is marked as dirty. When the transaction completes, these changes are flushed into persistent storage.

https://www.baeldung.com/jpa-hibernate-persistence-context

• 영속된 엔티티에 대하여 변경 사항이 발생할 때마다 계속 체크하고 있다가, 트랜잭션이 완료될 때 DB에 flush가 된다고 하네요.

• 결론부터 말씀드리자면 저는 틀린 말이라고 생각합니다..

위와 다르게, 영한님의 JPA 기본편 강의에서는

1. flush()가 발생

2. 영속성 컨텍스트의 1차 캐시를 뒤짐

3. 스냅샷과의 비교(변경 감지)

4. DB에 쿼리 update 쿼리 날림

이라고 말씀을 해주셨네요. 책에서 언급하신 것처럼요!

저는 y2gcoder님께서 말씀해주신 것처럼, 영속성 컨텍스트 입장에서 변경 감지를 계속 추적하려면 어떤 알고리즘인지는 모르겠지만 효율적인 측면에서 힘들지 않을까 싶어서, 영한님의 말씀이 맞다고 생각하고 있습니다. 굳이 flush 상황이 아니면 dirty가 발생할 때마다 변경 사항을 추적한다고 하더라도, 어차피 update 쿼리는 엔티티의 최종적인 상태(일반적으로는 커밋 시 호출되는 flush 상황의 엔티티)를 기준으로 날릴 것이기 때문에 또 굳이 "Persistence context keeps track of any changes made into a managed entity" 할 이유가 있나 싶습니다.

좀 지엽적인 고민같기는 하지만 최근 면접에서 제대로 답하지 못했던 내용이라 자꾸 마음이 쓰이네요..

그래도 친절하게 답변 달아 주셔서 감사합니다. 저도 제 생각을 공유 드리고 싶어서 댓글 남깁니다!

올려주신 답글과 링크 모두 잘 읽어보았습니다.
먼저 생각을 공유할 기회를 주셔서 정말 감사합니다.
저도 저 글을 보고나니 JPA가 그렇게까지 할 수 있다고? 라는 생각이 들어서 좀 더 찾아보다가 발견한 문서를 공유드리고자 합니다.

By default Hibernate checks all managed entity properties. Every time an entity is loaded, Hibernate makes an additional copy of all entity property values. At flush time, every managed entity property is matched against the loading-time snapshot value:

https://vladmihalcea.com/the-anatomy-of-hibernate-dirty-checking/

해당 아티클의 일부를 발췌해온 것입니다. 보면 하이버네이트의 Dirty Checking 전략에 대해 소개하면서 도표의 시작 시점을 flush 부터 잡고 있는 것을 볼 수 있습니다. 실제로 엔티티가 조회 될 때마다 그 시점의 엔티티의 모든 속성 값을 스냅샷에 저장해놓고, flush 했을 때 snapshot의 내용과 영속 상태의 엔티티의 속성값을 비교한다고 말하는데, 또 baeldung(저도 많이 봅니다.) 에서는 저렇게 말을 하고 있으니 좀 찝찝하긴 합니다.

아무튼 좋은 정보, 생각 공유해주셔서 감사합니다 :)

면접 파이팅하셔서 좋은 곳에 취직하시길 바랍니다 :)

자료 공유 감사합니다. 잘 읽어보았습니다.

올려 주신 설명에서는 또 Baeldung과 다르게 설명하고 있네요. 그런데 메서드 명까지 적어 놓은 것 보니 좀 더 신뢰가 가는..ㅋㅋㅋ

아무튼 이렇게 생각과 정보를 공유해주셔서 정말 감사합니다. 기술이란 것은 정말 하나하나 배워갈수록 더 깊이를 요구하게 되는 것 같습니다.

응원 정말 감사합니다!! 꼭 좋은 결과 내겠습니다!!

파이팅입니다 :)