1차 캐시 와 2차 캐시

네트워크를 통해 데이터베이스에 접근하는 시간 비용은 애플리케이션 서버에서 내부 메모리에 접근하는 시간 비용보다 수만에서 수십만 배 이상 비싸다. 따라서 조회환 데이터를 메모리에 캐시해서 데이터베이스 접근 횟수를 줄이면 애플이케이션 성능을 획기적으로 개선할 수 있다.


 영속성 컨텍스트 내부에는 엔티티를 보관하는 저장소가 있는데 이것을 1차 캐시라한다.

일잔적인 웹 애플리케이션 환경은 트랜젝션을 시작하고 종료할 때까지만 1차 캐시가 유효하다.

 하이버네이트를 포함한 대부분의 JPA 구현체들은 애플리케이션 범위의 캐시를 지원하는데 이것을 공유 캐시 또는 2차 캐시라 한다. 이런 2차 캐시를 활용하면애플리케이션 조회 성능을 향상 할 수 있다.

( JPA 책에서 현재 1차 2차 캐시 정보에 대한 부분이 나오는데,
사내에 구축되어 있는 OAuth 서버에 적용해서 DB 조회 부담을 덜어주는 방식으로 진행하면 좋을 것 같다.)

1 차 캐시 -> 2차 캐시 -> DB 조회
 (존재함)     (존재함)

사설이지만, 1,2차 캐시에 존재하면 바로 보내주면 되기 때문에 위에서 말했떤 네트워크 비용을 사용할 필요가 없다. 애플리케이션 내에서 확인 후 보내주면 된다. 하지만 1,2 차 캐시에 없으면 DB에 접근해서 조회쿼리등을 이용해서 가져와야하기 때문에 서버에 부하가 많이 걸릴 것이다.

https://brunch.co.kr/@sbcoba/7

이수홍님이 작성하신 JWT로 방식으로 바꾼다는 내용이 그 부분에 해당되는 것인지 궁금하다.
위 내용에 대해서는 Spring.io에서도 언급한 적이 있었는데. 그땐 내가 개념 이해하기 급급하여 제대로 확인하지 못했다.

 1차 캐시는 영속성 컨텍스 내부에 있다. 엔티티 매니저로 조회하거나 변경하는 모든 엔티티는 1차 캐시에 저장된다. (OSIV를 사용하면 Http 요청의 시작부터 끝까지 같은 영속성 컨텍스트를 유지)

1차 캐시는 끄고 켤 수 있는 옵션이 아니다. 영속성 컨텍스트 자체가 사실상 1차 캐시다.

따라서 1차 캐시는 같은 엔티티가 있으면 해당 엔티티를 그대로 반환한다. 따라서 1차 캐시는 객체 동일성(a == b)를 보장한다.

1차 캐시는 기본적으로 영속성 컨텍스트 범위의 캐시다.
(컨테이너 환경에서는 트랜잭션 범위의 캐시, OSIV를 적용하면 요청 범위의 캐시다).


2차 캐시

애플리케이션에서 공유하는 캐시를 JPA는 공유 캐시(shared cache) 라 하는데 일반적으로 2차 캐시 second level cache, L2 cache라 부른다. 2차 캐시는 애플리케이션 범위의 캐시다.

따라서 애플리케이션을 종료할 때까지 캐시가 유지된다. 분산 캐시나 클러스터링 환경의 캐시는 애플리케이션보다 더 오래 유지될 수도 있다.

2차 캐시를 적절히 활용하면 데이터베이스 조회 횟수를 획기적으로 줄일 수 있다.


JPA 2차 캐시 기능
JPA 구현체 대부분은 캐시 기능을 각자 지원했는데 JPA는 2.0에 와서야 캐시 표준을 정의했다. JPA 캐시 표준은 여러 구현체가 공통으로 사용하는 부분만 표준화해서 세밀한 설정을 하려면 구현체에 의존적인 기능을 사용해야 한다. 

캐시 모드 설정 !!?!??!?