Hibernate 학습 노트 | 2 급 캐 시 분석

캐 시
컴퓨터 분야 에서 매우 통용 되 는 개념 은 응용 프로그램 과 영구적 인 데이터 저장 원 (예 를 들 어 하 드 디스크 의 파일 이나 데이터 베이스) 사이 에 있 는데 그 역할 은 응용 프로그램 이 영구적 인 데이터 저장 원 을 직접 읽 고 쓰 는 빈 도 를 낮 추어 응용 운행 성능 을 향상 시 키 는 것 이다. 저장 중인 데 이 터 는 데이터 저장 원 에서 데 이 터 를 복사 하 는 것 이다.캐 시 된 물리 미디어 는 보통 메모리 입 니 다.
Hibernate 에서 제공 하 는 두 단계 의 캐 시:

첫 번 째 단계 의 캐 시: Session 단계 의 캐 시 는 사무 범위 에 속 하 는 캐 시 입 니 다. 이 단계 의 캐 시 는 Hibernate 에서 관리 합 니 다.

두 번 째 단계 의 캐 시: Session Factory 단계 의 캐 시 는 프로 세 스 범위 에 속 하 는 캐 시 입 니 다.

Session Factory 급 캐 시
Session Factory 급 캐 시 는 두 가지 로 나 눌 수 있 습 니 다.

내 장 된 캐 시 Hibernate 는 자체 적 으로 마 운 트 해제 가 불가능 합 니 다. 보통 Hibernate 초기 화 단계 에서 Hibernate 는 매 핑 메타 데이터 와 미리 정 의 된 SQL 문 구 를 Session Factory 캐 시 에 넣 습 니 다. 매 핑 메타 데 이 터 는 매 핑 파일 의 데이터 (hbm. xml 파일 의 데이터) 를 복사 합 니 다. 이 내 장 된 캐 시 는 읽 기 전용 입 니 다.

외부 캐 시 (2 급 캐 시) 설정 가능 한 캐 시 플러그 인 입 니 다.기본 적 인 상황 에서 Session Factory 는 이 캐 시 플러그 인 을 사용 하지 않 습 니 다. 외부 캐 시 에 있 는 데 이 터 는 데이터베이스 데이터 의 복사 이 고 외부 캐 시 에 있 는 물리 적 미디어 는 메모리 나 하 드 디스크 일 수 있 습 니 다.

Hibernate 의 2 급 캐 시
2 급 캐 시 에 넣 기 좋 은 데이터:

수정 되 지 않 음

중요 한 데이터 가 아니 라 가끔 병발 문제 가 발생 할 수 있 습 니 다

2 급 캐 시 에 넣 기 에 적합 하지 않 은 데이터:

자주 수정

재무 데 이 터 는 병발 문제 가 발생 하 는 것 을 절대 허락 하지 않 는 다

다른 응용 프로그램 과 공유 한 데이터

2 급 캐 시 병행 접근 정책
두 개의 동시 다발 적 인 업무 가 지구 층 의 캐 시 와 같은 데 이 터 를 동시에 방문 할 때 여러 가지 동시 다발 문제 가 발생 할 수 있 습 니 다.
2 급 캐 시 는 다음 과 같은 4 가지 유형의 동시 접근 정책 을 설정 할 수 있 습 니 다. 모든 접근 정책 은 하나의 트 랜 잭 션 격 리 단계 에 대응 합 니 다.

비 엄격 한 읽 기와 쓰기 (Nostrict - read - write) 는 캐 시 와 데이터베이스 에 있 는 데이터 의 일치 성 을 보장 하지 않 고 read Uncommitted 트 랜 잭 션 격 리 단 계 를 제공 합 니 다. 수정 되 지 않 고 더러 운 읽 기 를 허용 하 는 데 이 터 는 이러한 정책 을 사용 할 수 있 습 니 다.

읽 기 쓰기 형 (Read - write) 은 Read Committed 데이터 격 리 단 계 를 제공 합 니 다. 자주 읽 지만 수정 되 지 않 는 데이터 에 대해 서 는 이러한 격 리 유형 을 사용 할 수 있 습 니 다.더러 운 독 서 를 막 을 수 있 기 때문이다.

사무 형 (Transactional) 은 관리 환경 에서 만 적용 되 며 Repeatable Read 사무 격 리 단 계 를 제공 합 니 다. 자주 읽 지만 수정 되 지 않 는 데이터 에 대해 서 는 더러 운 읽 기와 중복 읽 기 를 방지 할 수 있 기 때 문 입 니 다.

읽 기 전용 (Read - Only) 은 Serializable 데이터 격 리 단 계 를 제공 합 니 다. 수정 되 지 않 은 데이터 에 대해 서 는 이러한 접근 전략 을 사용 할 수 있 습 니 다.

프로 세 스 범위 내의 2 급 캐 시 를 설정 하 는 절차

2 급 캐 시 플러그 인 을 추가 한 jar 패키지 및 프로필 jar 패 키 지 는 다음 과 같 습 니 다. ehcache-2.10.6.jar, hibernate-ehcache-5.4.3.Final.jar, slf4j-api-1.7.25.jar.설정 파일 ehcache. xml 는 다음 과 같 습 니 다:

Hibernate. cfg. cml 파일 설정 hibernate 의 2 급 캐 시 사용: true Hibernate 2 급 캐 시 사용 제품 설정: org.hibernate.cache.ehcache.internal.EhcacheRegionFactory Hibernate 를 사용 하 는 2 급 캐 시 설정:

실제로 .hbm.xml 파일 에서 2 급 캐 시 와 2 급 캐 시 를 사용 하 는 정책 을 설정 할 수 있 습 니 다.예 를 들 어 Employee.hbm.xml 파일 의 class 노드 에 를 추가 합 니 다.
2 급 캐 시 를 설정 한 후 다음 과 같이 테스트 합 니 다.

@org.junit.Test
    public void testHibernateSecondLevelCache(){
        Employee employee = session.get(Employee.class,1);
        System.out.println(employee.getName());
        //  session     
        transaction.commit();
        session.close();
        session = sessionFactory.openSession();
        transaction = session.beginTransaction();
        Employee employee1 = session.get(Employee.class,1);
        System.out.println(employee1.getName());

    }

2 급 캐 시 를 설정 하지 않 았 을 때 이 상황 은 sql 문 구 를 두 번 보 냅 니 다. 중간 에 닫 혔 기 때 문 입 니 다 session.2 급 캐 시 를 설 정 했 기 때문에 sql 문 구 를 보 낼 수 밖 에 없습니다.
집합 단계 의 2 급 캐 시 설정

집합 에 2 급 캐 시 를 사용 하도록 설정 합 니 다. 예 를 들 어 파일 에서 hbm.xml 탭 을 사용 하여 설정 할 수 있 습 니 다.

집합 에 있 는 요소 에 대응 하 는 지구 화 클래스 도 2 급 캐 시 를 사용 해 야 합 니 다. 그렇지 않 으 면 n 개의 SQL 문 구 를 더 사용 할 것 입 니 다.

Department 의 경우 프로필 은 다음 과 같 습 니 다.

    
        
        com.mysql.jdbc.Driver
        jdbc:mysql://localhost:3306/hibernate5
        root
        root

        
        
        org.hibernate.dialect.MySQL5Dialect
        
        true
        
        true
        
        update
        
        2
        true

        
        org.hibernate.c3p0.internal.C3P0ConnectionProvider
        10
        5
        2
        2000
        2000
        10

        
        100
        
        30


        
        true
        
        org.hibernate.cache.ehcache.internal.EhcacheRegionFactory

        
        

        
        
        
        
    

테스트:

@org.junit.Test
    public void testCollectionSecondLevelCache(){
        Department department = session.get(Department.class,1);
        System.out.println(department.getName());
        System.out.println(department.getEmps().size());
        transaction.commit();
        session.close();
        session = sessionFactory.openSession();
        transaction = session.beginTransaction();

        Department department1 = session.get(Department.class,1);
        System.out.println(department1.getName());
        System.out.println(department1.getEmps().size());

    }

ehcache. xml 파일 에 대한 분석

몇 개의 태그 에 대하 여

hibernate.cfg.xml 탭 에서 디 렉 터 리 를 지정 합 니 다. EHcache 가 하 드 디스크 에 데 이 터 를 쓸 때 이 디 렉 터 리 에 데 이 터 를 기록 합 니 다

탭 에 캐 시 를 설정 하 는 기본 데이터 만 료 정책

탭 은 구체 적 인 이름 캐 시 데이터 만 료 정책 을 설정 합 니 다. 이름 캐 시 마다 캐 시 영역

을 대표 합 니 다.
Hibernate 는 서로 다른 캐 시 영역 에 서로 다른 클래스 / 집합 을 저장 합 니 다. 클래스 에 있어 지역 의 이름 은 클래스 이름 입 니 다. 예 를 들 어 집합 에 있어 지역 의 이름 은 클래스 이름과 속성 명 입 니 다. 예 를 들 어 com.cerr.domain.Customercache 요소 의 속성

com.cerr.domain.Customer.orders: 캐 시 이름 을 설정 합 니 다. 이 값 은 클래스 의 전체 이름 이나 클래스 의 집합 이름 입 니 다.

name: 메모리 기반 캐 시 에 저장 할 수 있 는 대상 의 최대 수 를 설정 합 니 다.

maxInMemory: 설정 대상 이 영구적 인지, etemal 기한 이 지나 지 않 음 을 표시 합 니 다. 이 때 true 와 timeToldleSeconds 속성 을 무시 합 니 다. 기본 값 은 timeToLiveSeconds 입 니 다.

false: 대상 이 가장 오래 남 았 고 초 단위 로 이 시간 을 초과 하여 대상 이 만 료 되 었 습 니 다.대상 이 만 료 되면 EHcache 는 캐 시 에서 지 웁 니 다.이 값 이 0 이면 대상 이 무기한 으로 빈 상태 에 있 을 수 있 음 을 나타 낸다.

timeToldleSeconds: 대상 이 가장 오래 생존 하고 이 시간 을 초과 하면 대상 이 만 료 됩 니 다.이 값 이 0 이면 대상 이 캐 시 에 무기한 존재 할 수 있 음 을 나타 내 며, 이 속성 값 은 timeToLiveSeconds 속성 값 보다 크 거나 같 아야 합 니 다.

timeToldleSeconds: 내 장 된 캐 시 를 기반 으로 하 는 대상 의 수량 이 상한 선 에 이 르 렀 을 때 넘 치 는 대상 을 하 드 디스크 기반 캐 시 에 쓸 지 여부 입 니 다.

캐 시 조회
기본적으로 설 정 된 캐 시 는 HQL 및 QBC 조회 에 유효 하지 않 지만 검색 캐 시 설정 을 통 해 두 가지 조 회 를 지원 할 수 있 습 니 다.
설정 한 단계:

overflowToDisk 파일 에서 조회 캐 시 를 엽 니 다. 예 를 들 어 hibernate.cfg.xml

호출 true 또는 Query 의 Criteria.

메모: 캐 시 를 조회 하 는 것 은 2 급 캐 시 에 의존 합 니 다. 즉, 캐 시 를 조회 하려 면 2 급 캐 시 를 설정 해 야 합 니 다. 그렇지 않 으 면 사용 할 수 없습니다.
데 모 는 다음 과 같 습 니 다:

@org.junit.Test
    public void testQueryCache(){
        Query query = session.createQuery("FROM Employee ");
        //      
        query.setCacheable(true);

        List employees = query.list();
        System.out.println(employees.size());

        employees = query.list();
        System.out.println(employees.size());
    }

타임 스탬프 캐 시 영역
타임스탬프 캐 시 영역 은 검색 결과 와 관련 된 시 계 를 삽입, 업데이트 또는 삭제 하 는 타임 스탬프 를 저장 합 니 다. Hibernate 는 타임 스탬프 캐 시 영역 을 통 해 캐 시 된 검색 결과 가 만 료 되 었 는 지 여 부 를 판단 합 니 다. 그 실행 과정 은 다음 과 같 습 니 다.

T1 시간 에 조회 작업 을 수행 하고 조회 결 과 를 Query Cache 구역 에 저장 하 며 이 구역 의 시간 스탬프 를 T1 으로 기록 합 니 다.

T2 시간 에 조회 결과 와 관련 된 표를 업데이트 하고 Hibernate 는 T2 시간 을 UpdateTimestampCache 구역 에 저장 합 니 다.

T3 시간 에 조회 결 과 를 실행 하기 전에 Query Cache 구역 의 시간 스탬프 와 UpdateTimestampCache 구역 의 시간 스탬프 를 비교 하고 T2 ＞ T1 이 있 으 면 Query Cache 구역 에 저 장 된 조회 결 과 를 버 리 고 데이터베이스 에 다시 가서 데 이 터 를 조회 한 다음 에 결 과 를 Query Cache 구역 에 저장 합 니 다.약 T2

Query 인터페이스의 iterate () 방법setCacheable(true) 와 마찬가지 로 조회 작업 도 수행 할 수 있다.list() 실 행 된 SQL 문 구 는 실체 류 에 대응 하 는 데이터 시트 의 모든 필드 를 포함한다.list() 실 행 된 SQL 구문 에는 실체 클래스 에 대응 하 는 데이터 시트 의 ID 필드 만 포 함 됩 니 다.방문 결과 집합 을 옮 겨 다 닐 때 이 방법 은 Session 캐 시 및 2 급 캐 시 에서 특정 OID 대상 이 존재 하 는 지 확인 하고 존재 하 는 경우 해당 대상 으로 되 돌아 가 해당 대상 이 존재 하지 않 으 면 해당 SQL Select 문 구 를 통 해 데이터베이스 에 특정 실체 이미 지 를 불 러 옵 니 다.
대부분의 경우 iterator() 를 사용 하여 조회 작업 을 수행 하 는 것 을 고려 해 야 한다. list() 다음 과 같은 조건 을 만족 시 키 는 경우 에 만 조회 성능 을 약간 향상 시 킬 수 있다.

조회 할 데이터 시트 에는 대량의 필드 가 포함 되 어 있다

2 급 캐 시 를 사용 하고 2 급 캐 시 에 조회 대상 이 포함 되 어 있 을 수 있 습 니 다.