반응형

DirtyChecking 2

[Spring JPA 공식 문서 기반] 6. Flush는 왜 이렇게 예측하기 어려울까

5편에서는 JPA의 변경 감지(Dirty Checking)가“객체의 상태 변화를 SQL로 번역하는 규칙”이라는 점을 살펴봤습니다.이번 글에서는 그 다음 단계에서 가장 많은 혼란을 만드는 개념,Flush를 “쓰기 SQL과의 관계”를 중심으로 공식 문서 관점에서 정리해보겠습니다.Flush를 이해하지 못하면,왜 읽기 쿼리 전에 UPDATE가 나가는지왜 SQL은 나갔는데 롤백되는지왜 실행 시점을 코드로 예측할 수 없는지를 끝까지 설명할 수 없습니다.1. Flush를 Commit으로 이해하는 순간 문제가 시작된다Flush를 처음 접하면 대부분 이렇게 이해합니다.“Flush는 Commit 직전에 실행되는 과정이다”이 설명은절반만 맞고, 절반은 틀립니다.공식 문서 기준으로 두 개념은 명확히 구분됩니다.Flush – ..

[Spring JPA 공식 문서 기반] 5. 변경 감지(Dirty Checking)는 왜 이렇게 구현됐을까

4편에서는 Persistence Context가 단순한 캐시가 아니라,엔티티의 상태와 동일성을 지키기 위한 규칙 집합이라는 점을 살펴봤습니다.이번 글에서는 그 Persistence Context가 가장 강하게 모습을 드러내는 지점,변경 감지(Dirty Checking)를 공식 문서 관점에서 구조적으로 풀어보겠습니다.1. JPA에서 UPDATE는 왜 직접 호출하지 않을까JPA를 처음 접하면 이 점이 가장 낯설게 느껴집니다.member.setName("newName");// update 쿼리는 어디 있지?SQL을 직접 쓰던 시절이라면, 이 코드는아무 일도 하지 않은 코드처럼 보입니다.하지만 JPA에서는 이 한 줄이UPDATE SQL의 의도를 표현합니다.이게 가능한 이유가 바로 변경 감지입니다.2. 변경 감지..

반응형