JPA 2차 캐시란

intro
우리는 개발할때 서비스에 데이터를 보여주기 위해서 애플리케이션에서 데이터베이스를 연결한다.
만약 실시간으로 변경되는데 영향도가 낮은 데이터를 보여주는데 매번 데이터베이스를 연결하면 어떨가?
heap 메모리에서 데이터를 조회하는 것과 데이터베이스에서 데이터를 조회하는데 드는 시간비용을 비교한다면 
수만에서 수십만 배 이상 비싸다고 한다.
그렇다면 인메모리 캐시를 이용해서 데이터를 저장한다면 훨씬 빠르게 데이터를 클라이언트에 보여줄 수 있지 않을까?

 

 

1차 캐시와 2차 캐시

2020/04/13 - [개발/spring-boot] - JPA 애플리케이션 영속성 관리

 

영속성 컨텍스트 내부에는 엔티티를 보관하는 영역이 있다. 이는 1차캐시라고 한다,

 1차 캐시로도 이점이 많지만 애플리케이션 환경은 트랜잭션을 시작하고 종료할 때까지만 1차 캐시가 유효하다

 

따라서 애플리케이션 전체적으로 보면 데이터베이스 접근 횟수를 획기적으로 줄일 수 없다. 

-> 애플리케이션에서 보통 클라이언트가 요청이 오면 스레드가 생기고 해당 스레드에서 커넥션이 발생하기 때문에

 

하이버네이트를 포함한 대부분의 JPA 구현체들은 애플리케이션 범위의 캐시를 지원하는데 이것을 2차 캐시라 한다.

 

1차 캐시는 트랜잭션이 시작할때 영속성 컨텍스트가 생성되고 트랜잭션이 종료될때 영속성 컨텍스트가 종료되면서 사라진다. 

-> 물론 OSIV 를 사용하면 요청 ( filter servlet 이나 interceptor 를 통해 들어오는 request )  시작부터 끝가지 같은 영속성 컨텍스트를 유지하긴 한다.

1차 캐시는 기본적으로 영속성 컨텍스트 범위의 캐시이다.

 

2차 캐시는 애플리케이션 범위의 캐시이다. 따라서 애플리케이션이 종료될때까지 유지된다. 

2차 캐시는 조회된 객체를 그대로 반환하지 않는다.

-> 그러면 동시성이 극대화 된다. 락을 걸수도 있겠지만 락을 거는 비용보다 복사하는 비용이 저렴하다.

-> 복사본을 반환하기 때문에 동일성을 보장하지 않는다.

 

2차 캐시는 

 

엔티티 영역에서

 

1.1 엔티티 캐시 영역과

1.2 컬렉션 캐시 영역이 있고

 

2.1 쿼리 캐시영역이 존재한다.

 

-> 자세한 사용방법은 JPA 책이나 인터넷에 정보가 있다.

 

2차 캐시사용의 주의점

쿼리캐시와 컬렉션 캐시는 결과 집합의 식별자 값만 캐시한다. 

-> N+1 문제가 발생할 수 있다.