Jpa hibernate의 2차 캐시

 

 

 

 

JPA에서는 영속성 컨텍스트를 기반으로 돌아간다.

 

그 중심에 명령어를 저장하는 쓰기지연 저장소와 엔티티를 저장하는 1차 캐시가 있다는 것은 알고있었다.

 

이를 통해 DB 커넥션으로 데이터를 주고받는 작업을 최소화해서 성능상의 이점을 가져갈 수 있다는 것까지는 이해했다.

 

 

여기서 1차 캐시는 하나의 트랜잭션 단위에서 저장된다.

즉 해당 트랜잭션이 끝나면 다 날라간다.

1차캐시는 JPA의 고유 기능이라 on/off 할 수 없는 당연한 존재다.

 

문득 새삼 그런 생각이 들었다

 

트랜잭션 단위는 캐시의 특성을 활용하기엔 그다지 효율적일 것 같지 않은데?..

그 위에 애플리케이션 메모리 단위에서 캐시 저장소가 필요할 것 같은데?

 

---

 

Jpa에는 2차 캐시도 존재한다!

 

 

2차캐시의 동작 원리는 찾고자하는 엔티티가 1차 캐시에 없을 때 2차 캐시에서 찾는 방식이다.

 

위의 그림을 보면

 

2차 캐시에 저장되어 있는 엔티티를 조회하면 복사본을 만들어 반환한다.

 

그대로 반환하면 여러 곳(영속성컨텍스트)에서 같은 엔티티를 동시에 수정하는 문제가 발생할 수 있기 때문이다.

 

(락을 사용하기엔 동시성 관점에서 성능이 떨어질 수 있다)

 

그 외의 다음과 같은 특징이 있다.

 

• 당연하게도 2차 캐시는 데이터베이스 기본 키를 기준으로 캐시하지만 영속성 컨텍스트가 다르면 객체 동일성 보장하지 않는다.
• 2차 캐시는 애플리케이션을 종료할 때까지 캐시가 유지된다.

---

 

JPA에서 캐시 사용법

 

@EnableCaching
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

메인 메서드에 @EnableCaching 어노테이션을 추가해야한다

 

캐시 관련 어노테이션

 

--- 엔티티 단위에 설정
@Cacheable : 동일한 파리 미터로 메서드를 호출 이력과 반환 결과가 캐시에 저장되어 있으면, 캐시를 사용함

--- 메서드 단위에 설정
@CacheEvict : 캐시에 저장된 호출 이력 및 결과 값을 삭제함.
@CachePut : 캐시에 저장된 결괏값을 업데이트함

-- Config
@CacheConfig : 캐시 옵션을 메서드 단위가 아닌 클래스 단위로 설정하고자 할 때 사용.

 

@Cache

 

엔티티 단위에 붙이는 어노테이션으로서

캐시에 대한 작업시 동시성을 생각해서 작동하는 것이다.

READ_ONLY : 읽기 전용으로 사용 (update 하려고 하면 exception을 던짐)
간단하고 성능이 좋음
항상 변하지 않는 데이터를 대상으로 사용하는게 좋음

NONSTRICT_READ_WRITE:
객체 동시 수정 등에 대한 고려를 전혀 하지 않고 캐싱
이 방식은 하나의 객체가 동시에 수정될 가능성이 거의 없는 경우에 사용

READ_WRITE: 엄격한 읽기/쓰기로 두 개 이상의 스레드에서 동시 수정할 가능성에 대해서 고려하고 만들어야 함

 

 

 

 

Reference

 

- https://junghyungil.tistory.com/203

- https://velog.io/@wnguswn7/JPA-%EC%BA%90%EC%8B%9CCache%EC%9D%98-%EC%B6%94%EC%83%81%ED%99%94%EC%99%80-%EC%82%AC%EC%9A%A9-Cacheable-CachePut-CacheEvict

- https://develoyummer.tistory.com/87