6. JPA의 캐시

cf) 캐시(Cache)

: 사용되었던 데이터는 다시 사용될 가능성이 높다는 개념을 이용하여 데이터나 값을 미리 복사해놓는 임시 저장소

- DB는 Secondary Memory에 저장됨

-> 캐시 메모리에 접근하면 훨씬 빠름

- 캐시는 성능 개선에 도움이 되기 때문에, 컴퓨터 전반에 걸쳐 많은 곳에서 사용됨

- EX )

• CPU - L1, L2, L3
• DRAM, HDD
• CDN
• HTTP Cache
• Application Cache
• Proxy Cache

1차 캐시(First-Level-Cache)

: 영속성 컨텍스트 내부에 엔티티를 저장하여 빠른 데이터 조회와 업데이트를 지원하는 메모리 기반 캐시

- 객체의 동일성을 보장함

 

1. 1차 캐시 조회 과정

• 1차 캐시에 엔티티가 있는 경우
  1. 엔티티 조회
  2. 1차 캐시에서 결과 반환
• 1차 캐시에 엔티티가 없는 경우
  1. 엔티티 조회
  2. DB 조회
  3. 1차 캐시에 결과 저장
  4. 저장한 결과 반환

- 최종적으로 트랜잭션이 커밋되거나 플러시를 호출하면 1차 캐시의 엔티티 변경 내역이 DB에 동기화됨

 

2. 1차 캐시의 한계

- 트랜잭션 범위 내에서만 유효함

- 트랜잭션이 커밋되거나 롤백되면 1차 캐시에 저장된 엔티티는 삭제되고, 다음 트랜잭션에서는 다시 DB에서 조회하게 됨

 

2차 캐시(Second-Level-Cache)

: 애플리케이션에서 공유하는 캐시

- JPA에서는 공유 캐시라고 함

- 일반적으로는 2차 캐시라고 함

- 애플리케이션을 종료할 때까지 캐시가 유지됨

- 영속성 컨텍스트가 다르면 객체 동일성을 보장하지 않음

 

1. 2차 캐시 조회 과정

• 2차 캐시에 엔티티가 있는 경우
  1. 엔티티 조회
  2. 2차 캐시에서 결과 반환
• 2차 캐시에 엔티티가 없는 경우
  1. 엔티티 조회
  2. DB 조회
  3. 2차 캐시에 결과 저장
  4. 2차 캐시는 복사본을 만들어서 1차 캐시에 반환

 

2. 2차 캐시가 복사본을 반환하는 이유

=> 동시성

- 캐시한 객체를 그대로 반환하면 멀티 스레드 환경에서 동시성 이슈가 발생할 수 있음

-> 캐시한 객체를 여러 곳에서 수정하는 문제가 발생할 수 있음

- 이를 해결하기 위해서 락을 거는 방법도 있는데, 락을 사용해서 해결하는 것보다 객체를 복사해서 반환하는 것의 비용이 더 저렴함

 

3. 실무에서 2차 캐시

- Hibernate 2차 캐시보다는 Spring이 지원하는 캐시를 서비스 계층에서 사용하는 게 더 효과적

- 2차 캐시는 설정도 복잡하고, 지원하는 캐시 라이브러리도 작음

- 실무에서는 서비스 계층에서 복잡하게 외부 API도 호출하고, 여러 엔티티도 조회해서 그 결과로 DTO를 생성

- Spring을 사용하면 이 DTO를 효과적으로 캐시할 수 있고, 지원하는 캐시 라이브러리도 풍부함

- 2차 캐시는 단순히 엔티티 조회와 관련된 부분만 캐시가 지원됨