인프런 커뮤니티 질문&답변
작성한 질문수
주문취소시 영속성 컨텍스트
작성
·
230
6
썜.
//주문취소
order.cancel();
을 했을경우. 카운트만 바꾸었지 persist를 한적이 없잖아요?
그상태로 @Transactional때문에 commit이 날라가게 될텐데 어떻게 카운트 값이 db에 번복되어 저장되는것이죠?
고비 같군요 지금이..
답변 3
4
안녕하세요. 윽이럴뚜가님
이것이 바로 JPA의 큰 장점중 하나인 변경감지(Dirty checking) 기능입니다.
JPA를 통해서 order 엔티티를 조회하는 순간 JPA는 원본 데이터를 복사해서 내부에 하나 더 가지고 있습니다. 이것을 스냅샷이라고 합니다. 이 스냅샷은 우리가 접근할 수 없고, order 엔티티를 조회했던 시점의 상태를 가지고 있습니다.
그리고 우리는 order 엔티티의 값을 변경하게 되겠지요.
이후에 트랜잭션이 커밋되는 순간 내부에서 플러시가 발생하면서 JPA는 변경감지를 실행합니다. 최초 데이터 상태인 스냅샷과 order 엔티티의 값이 같은지 다른지 비교하는 과정이지요.
이 과정을 통해서 order 엔티티의 값이 변경된 것을 인지할 수 있습니다.
그리고 order 엔티티의 값이 변경되었다면 update 쿼리가 실행됩니다^^!
바로 이 변경감지 덕분에 개발자는 엔티티 객체의 값만 변경해도 JPA가 update 쿼리를 만들어서 데이터베이스에 변경하는 과정은 자동으로 처리되는 것이지요.
참고로 변경 감지는 트랜잭션 범위 안에서 엔티티 객체를 조회했을 때만 동작합니다.
JPA의 이러한 내부 메커지즘에 대해서는 JPA 기본편에서 매우 자세히 알려드립니다^^!
감사합니다.
1
아...그렇군요...cancel전에 order를 find했으니 1차캐시에 있겠군요....
여기서 set을 해버리면 insert때리는 거구요.
제가 주의깊게 안본것 같네요.
감사합니다 !!^^~ 역시 굿!쌤
0