현재 개발중인 프로젝트에서 어떤 데이터 값이 삽입,수정,삭제 쿼리는 거의 일어나지 않고, 조회 쿼리만 일어나고 있다.
매번 DB에 접근하는 것보다는 JPA에서 지원해주는 2차 캐시 를 사용한다면 애플리케이션 단위에서 조회가 완료되어 성능이 개선될 것 같다는 생각이들었다.
따라서 2차 캐시를 알아보고 적용해보자!
내 상황
👤 유저는 다른 유저👤 에게 카드🃏를 주고 받을 수 있다.
이때 이 카드는 사용자가 커스터마이징하는 것이 아니라, 전달만 가능하게 되어있다.
이때 유저에게 전달하려는 카드 번호를 받아, 해당 카드가 DB에서 정상 조회 후 전달 정보를 만들게 되어있다.이때 매번 영속성 컨텍스트가 종료되어 반복적인 DB 조회 작업을 하게된다.
1차 캐시와 2차 캐시
1차캐시는 영속성 컨텍스트마다 생성되는 공간이다. 영속성 컨텍스트끼리 1차캐시를 공유하지 않기 때문에 반복적인 조회 쿼리가 발생할 수 있다.
2차 캐시는 애플리케이션 전체 단위가 공유하는 캐시다. 여러 곳에서 반복적으로 엔티티를 조회하지 않고, 2차 캐시에 있는지 살펴 본 후 조회하기 때문에 반복적인 작업을 줄여준다.
애플리케이션 전체 단위라는 말을 애플리케이션 범위의 캐시라고도 한다.
2차 캐시의 동작 방식을 좀 더 상세하게 알아보자.
- 영속성 컨텍스트가 2차 캐시에서 엔티티를 조회한다.
- 2차 캐시에 엔티티가 없으면 데이터 베이스를 조회 후, 2차 캐시에 저장한다.
- 2차 캐시는 조회 요청에 객체를 복사에서 반환한다.
- 또 다른 영속성 컨텍스트가 2차 캐시에 엔티티를 조회 시 2차 캐시는 DB 접근하지 않고 3번 과정을 반복한다.
💡 왜 2차 캐시는 복사해서 제공할까?
2차 캐시의 엔티티를 그대로 반환 후 해당 엔티티를 실수로 수정했다고 해보자.
그렇다면 의도하지않았지만 다른 곳에서도 예상치 못하게 수정이 되는 문제가 발생한다.관련해서 얕은 복사와 깊은 복사를 공부해봐도 좋을 것 같다.
다른 주소를 갖는 같은 인스턴스들
위의 사진에서 첫번째 영속성 컨텍스트에 저장된 엔티티와 두번째 영속성 컨텍스트의 엔티티, 세번째 경우 모두 id값이 동일하다. 그러나 주소값은 다르기 때문에 ==를 사용할 경우 실패한다.
이 경우에는 eqauls()메서드를 재 정의해야한다.
