Hibernate 의 1, 2 급 캐 시
캐 시 는 물리 적 데이터 원본 과 응용 프로그램 사이 에 있 으 며 데이터베이스 에 있 는 데 이 터 를 메모리 에 임시로 저장 하 는 용 기 를 복사 하 는 것 입 니 다. 응용 프로그램 이 물리 적 데이터 원본 에 접근 하 는 횟수 를 줄 이 고 응용 프로그램의 운행 성능 을 향상 시 키 는 역할 을 합 니 다.하 이 버 네 이 트 는 데 이 터 를 읽 을 때 캐 시 시스템 에 따라 해당 캐 시 에서 조회 하고 캐 시 에서 필요 한 데 이 터 를 찾 으 면 (우 리 는 이 를 '캐 시 명중' 이 라 고 부 릅 니 다) 명중 한 데 이 터 를 직접 결과 로 활용 하여 데이터베이스 에 SQL 문 구 를 대량으로 보 내 조회 하 는 성능 손실 을 피 할 수 있 습 니 다.
캐 시 정책 공급 자:
HashTable 캐 시, EHcache, OSCache, SwarmCache, jBoss 를 제공 합 니 다. Cathe 2, 이러한 캐 시 메커니즘, 그 중에서 EHcache, OSCache 는 클 러 스 터 환경 (Cluster) 에 사용 할 수 없습니다. Safe) 의, 그리고 SwarmCache, jBoss Cathe 2 는 가능 합 니 다. HashTable 캐 시 는 주로 테스트 용 입 니 다. 대상 을 메모리 에 만 넣 을 수 있 습 니 다. EHcache, OSCache 는 대상 을 메모리 (memory) 에 넣 을 수도 있 고 대상 을 하 드 디스크 (disk) 에 놓 을 수도 있 습 니 다.
Hibernate 캐 시 분류:
1. Session 캐 시 (트 랜 잭 션 캐 시 라 고도 함): Hibernate 에 내 장 된 것 으로 제거 할 수 없습니다.
캐 시 범위: 캐 시 는 현재 세 션 대상 에 만 접근 할 수 있 습 니 다. 캐 시 수명 주 기 는 세 션 의 수명 주기 에 의존 합 니 다. 세 션 이 닫 히 면 캐 시가 수명 주 기 를 끝 냅 니 다. 이것 이 바로 1 급 캐 시 입 니 다.
2. Session Factory 캐 시 (응용 캐 시 라 고도 함): 제3자 플러그 인 을 사용 하여 삽입 할 수 있 습 니 다.
캐 시 범위: 캐 시 는 응용 범위 내의 모든 session 에 의 해 공유 되 며, 서로 다른 Session 은 공유 할 수 있 습 니 다. 이 session 들 은 캐 시 에 동시에 접근 할 수 있 으 므 로 캐 시 를 업데이트 해 야 합 니 다. 캐 시 수명 주 기 는 응용 프로그램의 수명 주기 에 의존 합 니 다. 응용 이 끝 날 때 캐 시 는 수명 주 기 를 끝 냅 니 다. 2 급 캐 시 는 응용 프로그램 범위 에 존재 합 니 다.
1 레벨 캐 시:
Hibernate 1 급 캐 시 와 관련 된 동작 (시간):
데 이 터 를 캐 시 에 넣 기:
1. save (). session 대상 이 save () 방법 으로 대상 을 저장 하면 이 대상 은 session 캐 시 에 넣 습 니 다.
2. get () 과 load (). session 대상 이 get () 또는 load () 방법 으로 데이터베이스 에서 대상 을 꺼 내 면 이 대상 도 session 캐 시 에 넣 습 니 다.
3. 데이터베이스 에서 HQL 과 QBC 등 을 이용 해 데 이 터 를 조회 합 니 다.
예 를 들 어 데이터 베 이 스 는 다음 과 같은 표 가 있 습 니 다.
get () 또는 load () 를 사용 하여 캐 시 존 재 를 증명 합 니 다.
public class Client
{
public static void main(String[] args)
{
Session session = HibernateUtil.getSessionFactory().openSession();
Transaction tx = null;
try
{
/* */
tx = session.beginTransaction();
/* id="402881e534fa5a440134fa5a45340002" Customer */
Customer customer1 = (Customer)session.get(Customer.class, "402881e534fa5a440134fa5a45340002");
System.out.println("customer.getUsername is"+customer1.getUsername());
/* */
tx.commit();
System.out.println("-------------------------------------");
/* */
tx = session.beginTransaction();
/* id="402881e534fa5a440134fa5a45340002" Customer */
Customer customer2 = (Customer)session.get(Customer.class, "402881e534fa5a440134fa5a45340002");
System.out.println("customer2.getUsername is"+customer2.getUsername());
/* */
tx.commit();
System.out.println("-------------------------------------");
/* get() */
System.out.println("customer1 == customer2 result is "+(customer1==customer2));
}
catch (Exception e)
{
if(tx!=null)
{
tx.rollback();
}
}
finally
{
session.close();
}
}
}
프로그램 콘 솔 출력 결과:
Hibernate: select customer0_.id as id0_0_, customer0_.username as username0_0_, customer0_.balance as balance0_0_ from customer customer0_ where customer0_.id=?customer.getUsername islisi-------------------------------------customer2.getUsername islisi-------------------------------------customer1 == customer2 result is true
그 원 리 는 같은 Session 에서 get () 방법 을 첫 번 째 로 호출 하 는 것 입 니 다. Hibernate 는 캐 시 에 이 검색 대상 이 있 는 지 먼저 검색 한 결과 없 는 지 를 발 견 했 습 니 다. Hibernate 는 SELECT 문 구 를 데이터베이스 에 보 내 해당 대상 을 꺼 낸 다음 에 사용 할 수 있 도록 이 대상 을 캐 시 에 넣 습 니 다. 두 번 째 호출 get ()방법, Hibernate 는 캐 시 에 이 검색 대상 이 있 는 지 먼저 검색 합 니 다. 마침 이 검색 대상 이 있 는 것 을 발견 하면 캐 시 에서 꺼 내 데이터베이스 에서 검색 하지 않 고 selection 문 구 를 다시 보 내지 않 습 니 다.
캐 시 에서 데이터 지우 기:
1. evit () 는 지정 한 지구 화 대상 을 캐 시 에서 제거 하고 대상 이 사용 하 는 메모리 자원 을 방출 하 며 지정 한 대상 은 지구 화 상태 에서 탈 관 상태 로 바 꾸 어 유리 대상 이 됩 니 다. 2. clear () 는 캐 시 에 있 는 모든 영구적 인 대상 을 삭제 하고 사용 하 는 메모리 자원 을 방출 합 니 다.
다른 캐 시 작업:
1. contains () 지정 한 대상 이 캐 시 에 존재 하 는 지 판단 합 니 다. 2. flush () 캐 시 영역 내용 을 새로 고침 하여 데이터베이스 데이터 와 동기 화 합 니 다.
2 단계 캐 시:
@Test
public void testCache2() {
Session session1 = sf.openSession();// Session1
session1.beginTransaction();
Category c = (Category)session1.load(Category.class, 1);
System.out.println(c.getName());
session1.getTransaction().commit();
session1.close();
Session session2 = sf.openSession();// Session2
session2.beginTransaction();
Category c2 = (Category)session2.load(Category.class, 1);
System.out.println(c2.getName());
session2.getTransaction().commit();
session2.close();
}
세 션 을 다시 시작 하면 두 번 째 로 load 나 get 방법 으로 같은 대상 을 검색 할 때 데이터 베 이 스 를 다시 찾 고 selection 문 자 를 보 냅 니 다.
원인: 하나의 session 에서 다른 session 의 캐 시 를 가 져 올 수 없습니다.
성능 상의 문제: 만약 에 다 중 스 레 드 가 동시에 Category 라 는 대상 을 가 져 간다 면 load 대상 은 원래 메모리 에 넣 을 수 있 었 지만 다 중 스 레 드 이기 때문에 서로 다른 session 에 분포 되 어 있 기 때문에 매번 데이터 베이스 에서 가 져 와 야 합 니 다. 그러면 조회 성능 이 비교적 낮은 문 제 를 가 져 올 수 있 습 니 다.
솔 루 션: 2 급 캐 시 를 사용 합 니 다.
1. 2 급 캐 시가 무엇 입 니까?
Session Factory 급 캐 시 는 Session 을 뛰 어 넘 을 수 있 고 여러 Session 에서 공유 할 수 있 습 니 다.
2. 2 급 캐 시 에 넣 기:
(1) 자주 방문
(2) 변동 이 크 지 않다.
(3) 수량 제한
(4) 중요 한 데이터 가 아니 라 가끔 동시 다발 적 인 데이터 가 나 올 수 있 습 니 다.
이런 데 이 터 는 2 급 캐 시 에 넣 기 에 매우 적합 하 다.
사용자 의 권한: 사용자 의 수량 이 많 지 않 고 권한 이 많 지 않 으 며 자주 변경 되 지 않 고 자주 방문 합 니 다.
예 를 들 어 조직 기구.
사고: 어떤 종류, 안의 대상 이 2 급 캐 시 에 적합 합 니까?
변경 이 빈번 합 니 다. 클래스 에 대상 이 매우 많 습 니 다. BBS 에 많은 댓 글 이 있 습 니 다. 이 게시 물 들 은 20000 여 개 입 니 다. 어떤 것 을 캐 시 에 넣 었 는 지 확인 할 수 없습니다. 자주 방문 하 는 것 이 확실 하지 않 으 면 데이터 의 양 이 많 지 않 고 변경 이 매우 적 습 니 다. 이러한 데 이 터 는 2 급 캐 시 에 넣 기 에 매우 적합 합 니 다.
3. 2 급 캐 시 실현 원리:
하 이 버 네 이 트 는 데이터베이스 에 있 는 데 이 터 를 어떻게 2 단계 캐 시 에 저장 합 니까? 주의 하 세 요. 캐 시 를 Map 대상 으로 볼 수 있 습 니 다. Key 는 대상 OID 를 저장 하고 Value 는 POJO 를 저장 하 는 데 사 용 됩 니 다. 우선, 하 이 버 네 이 트 를 사용 하여 데이터베이스 에서 데 이 터 를 조회 하고 검색 한 데 이 터 를 가 져 오 면 하 이 버 네 이 트 는 검색 한 대상 의 OID 를 캐 시 에 넣 습 니 다 key 그 다음 에 구체 적 인 POJO 를 value 에 넣 고 다음 에 데 이 터 를 다시 조회 할 때 까지 기 다 립 니 다. Hibernate 는 제공 한 OID 에 따라 1 급 캐 시 를 먼저 검색 하고 2 급 캐 시 를 설정 하면 2 급 캐 시 를 검색 합 니 다. 아직 없 으 면 데이터베이스 에 SQL 문 구 를 보 낸 다음 에 조 회 된 대상 을 캐 시 에 넣 습 니 다.
4. 2 급 캐 시 사용
(1) 2 급 캐 시 열기:
Hibernate 를 위 한 2 단계 캐 시 설정:
주 프로필 에서 hibenate. cfg. xml :
(3) 2 급 캐 시 를 사용 하려 면 실체 클래스 에 주 해 를 추가 해 야 합 니 다.
ehcache - 1.2. jar 패키지 가 필요 합 니 다:
더 필요 하 다 commons loging 1.1.1. jar 패키지
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
Load 는 기본적으로 2 급 캐 시 를 사용 합 니 다. 대상 을 찾 을 때 2 급 캐 시 에서 찾 습 니 다. 찾 으 면 데이터베이스 에서 찾 지 않 습 니 다.
Iterator 는 기본적으로 2 급 캐 시 를 사용 합 니 다. 있 으 면 데이터베이스 에서 찾 지 않 고 selection 문 구 를 보 내지 않 습 니 다.
List 는 기본적으로 2 급 캐 시 에 데 이 터 를 추가 합 니 다. query 가 있 으 면 데 이 터 를 꺼 낸 후 2 급 캐 시 에 넣 습 니 다. 그러나 조 회 를 실행 할 때 2 급 캐 시 에서 찾 지 않 고 데이터베이스 에서 찾 습 니 다. 이 유 는 query 마다 조회 조건 이 다 르 기 때 문 입 니 다.
(4) 캐 시 대상 에 hbm 파일 의 < class > 탭 에 < cache > 하위 탭 을 추가 할 수도 있 습 니 다.
한 쌍 이상 의 관계 가 존재 합 니 다. 한 쪽 을 가 져 올 때 연 결 된 다 중 캐 시 를 하려 면 집합 속성 아래 < cache > 하위 탭 을 추가 해 야 합 니 다. 연 결 된 대상 의 hbm 파일 에 < class > 탭 아래 에 도 < cache > 탭 을 추가 해 야 합 니 다. 그렇지 않 으 면 Hibernate 는 OID 만 캐 시 합 니 다.
-->
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
[JPA] 즉시로딩(EAGER)과 지연로딩(LAZY) (왜 LAZY 로딩을 써야할까?) (1)Proxy는 이 글의 주제인 즉시로딩과 지연로딩을 구현하는데 중요한 개념인데, 일단 원리는 미뤄두고 즉시로딩과 지연로딩이 무엇인지에 대해 먼저 알아보자. 눈 여겨 볼 곳은 'fetch = FetchType.EAGER...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.