Spring Day 28 : 영속성 컨텍스트 특징

1차 캐시

영속성 컨텍스트는 내부적으로 Map을이용해서 엔티티들을 보관한다 이를 1차 캐시라고 한다. Key는 엔티티에 사용한 `@Id` 로 매핑한 식별자고, 값은 엔티티다.

데이터베이스를 조회하기 전 영속성 컨텍스트를 조회하기 때문에 영속성 컨텍스트에 엔티티가 있을 경우 추가적인 조회가 발생하면 성능상 이점을 가져갈 수 있다.

 

동일성 보장

앞서 1차 캐시 개념으로 생각해보면 당연한 얘기다. 1차 캐시에 있는 같은 엔티티 인스턴스를 반환하기 때문에 동일성을 보장해 줄 수 있다.

쓰기 지연

엔티티를 저장하면 엔티티 매니저는 영속성 컨텍스트에만 저장해 놓고 실제 데이터베이스에 sql을 날리지 않는다. 트랜잭션이 정상적으로 수행되어 커밋하는 순간 모아둔 insert sql들을 데이터베이스에 날린다. 한 번에 sql을 날리기 때문에 성능상 이점을 가져갈 수 있다. 이것을 쓰기 지연이라 한다.

 

더티 체킹

기본적으로 데이터에 변경이 있을 경우 `조회 쿼리 → 수정 → 수정 쿼리` 이런 식으로 작업을 진행해야 한다. 데이터 수정 쿼리에서도 실수가 발생할 수 있고, 비즈니스 로직이 sql에 의존하게 된다.

JPA에서는 이를 개선하고 더티 체킹이라는 개념을 도입한다. JPA는 엔티티를 영속성 컨텍스트에 보관할 때, 최초 상태에 대한 `스냅샷`을 갖고있는다. 그리고 `flush`가 발생하는 순간 스냅샷 시점과, 현재 엔티티를 비교하여 변경된 것이 있는지 확인한다. 변경된 엔티티가 있다면, sql을 저장해 두고 트랜잭션을 커밋하는 순간 sql을 날린다.

이러한 과정 덕에 JPA에서는 update를 사용하지 않고, 엔티티 데이터만 변경해주기만 하면 된다.