들어가기 앞서
오늘은 API를 열심히 짠 날이다!
4개를 완성했는데 시간이 왜 이렇게 금방 갔는지 알 수가 없다. 금방 완성한 API도 있었지만, 도저히 알 수가 없다.
API를 짜면서 한 번쯤은 생각해볼만한 것에 대해 작성해보려고 한다.
슈~웃!
회고
update 로직 작성 시, DB를 찌르지 않고도 Entity의 update 메서드로 업데이트가 되는 이유!
소제목이 이해가 되지 않는다면, 사진으로 이해를 해보자!
Category Entity에 있는 메서드이고, 서비스 로직도 확인해보자!
위 사진을 보면, 맨 마지막 부분에 category.update 를 하고 있는 것을 알 수 있다.
데이터 베이스를 찌르지도 않는데, 업데이트가 되는 놀라운 이유,,,
바로 Dirty Checking(더티 체킹) 때문이다.
위 사진에서는 JPA와 @Transactional 을 사용해 트랜잭션 안에서 작동함에 따라 Entity의 변경이 발생해 적용되는 것이다.
Dirty Checking이 뭔데!?
Transaction 안에서 Entity의 변경이 일어나면, 변경 내용을 자동적으로 DB에 반영하는 JPA 특징이다(@Transactional 같이 사용).
더티 체킹이 일어나는 조건은
1. 영속 상태에 있는 엔티티인 경우
2. 트랜잭션 안에서 엔티티 변경이 일어나는 경우위와 같이 2가지로 존재한다.
필자가 해당하는 경우는 2번이다!!
(서비스 레이어에서 @Transactional 어노테이션을 사용하기 때문)
JPA에서는 스냅샷이라는 것이 존재한다. 이는 최초 조회 시 데이터를 사진 찍듯이 등록한다.
그래서 트랜잭션이 작동하는 도중에 데이터가 스냅샷과 다를 시, Update 쿼리문을 DB에 날려준다. 따로 쿼리문이 날라가는 것을 사진 찍지는 않았지만, 직접 확인해보면 알 수 있다!!!
(단, 비영속, 준영속 상태는 불가능)
