최대 절전 모드의 첫 번째 및 두 번째 수준 캐시는 무엇입니까?
답변:
1.1) 1 차 캐시
첫 번째 레벨 캐시는 항상 세션 오브젝트 와 연관됩니다 . 최대 절전 모드는 기본적으로이 캐시를 사용합니다. 여기서는 하나의 트랜잭션을 차례로 처리하므로 한 트랜잭션을 여러 번 처리하지 않습니다. 주로 주어진 트랜잭션 내에서 생성해야하는 SQL 쿼리 수를 줄입니다. 즉, 트랜잭션에서 수행 된 모든 수정 후에 업데이트하는 대신 트랜잭션이 끝날 때만 트랜잭션을 업데이트합니다.
1.2) 2 차 캐시
2 단계 캐시는 항상 Session Factory 객체 와 연결됩니다 . 트랜잭션을 실행하는 동안 트랜잭션 사이에 세션 팩토리 레벨에서 오브젝트를로드하므로 해당 오브젝트는 단일 사용자에 바인드되지 않고 전체 애플리케이션에서 사용 가능합니다. 오브젝트는 캐시에 이미로드되어 있으므로 쿼리에서 오브젝트가 리턴 될 때마다 데이터베이스 트랜잭션을 수행 할 필요가 없습니다. 이런 식으로 두 번째 수준 캐시가 작동합니다. 여기서 쿼리 수준 캐시도 사용할 수 있습니다.
Streamline Logic 블로그 에서 첫 번째 수준 캐싱에 대한 좋은 설명이 있습니다.
기본적으로 첫 번째 레벨 캐싱은 두 번째 레벨 캐싱이 여러 세션에서 공유 될 수있는 세션별로 수행됩니다.
최대 절전 모드 캐시에 대한 기본 설명은 다음과 같습니다.
첫 번째 수준 캐시는 "세션"개체와 연결됩니다. 캐시 개체의 범위는 세션입니다. 세션이 종료되면 캐시 된 객체는 영구적으로 사라집니다. 첫 번째 수준 캐시는 기본적으로 활성화되어 있으며 비활성화 할 수 없습니다. 엔터티를 처음 쿼리하면 데이터베이스에서 엔터티를 검색하여 최대 절전 모드 세션과 관련된 첫 번째 수준 캐시에 저장합니다. 동일한 세션 객체로 동일한 객체를 다시 쿼리하면 캐시에서로드되고 SQL 쿼리가 실행되지 않습니다. 로드 된 엔티티는 evict()메소드를 사용하여 세션에서 제거 할 수 있습니다 . 이 엔티티의 다음로드는 evict()메소드를 사용하여 제거 된 경우 데이터베이스 호출을 다시 수행합니다 . clear()방법을 사용하여 전체 세션 캐시를 제거 할 수 있습니다 . 캐시에 저장된 모든 엔티티를 제거합니다.
두 번째 레벨 캐시는 세션 팩토리 범위에서 전체적으로 사용할 수있는 첫 번째 레벨 캐시와 다릅니다. 두 번째 레벨 캐시는 세션 팩토리 범위에서 작성되며 특정 세션 팩토리를 사용하여 작성된 모든 세션에서 사용할 수 있습니다. 또한 세션 팩토리가 닫히면 이와 관련된 모든 캐시가 죽고 캐시 관리자도 닫힙니다. 최대 절전 모드 세션이 엔티티를로드하려고 할 때마다 첫 번째 레벨 캐시에서 첫 번째 레벨 캐시에서 캐시 된 엔티티 사본을 찾습니다 (특정 최대 절전 모드 세션과 연관 됨). 캐시 된 엔터티 복사본이 첫 번째 수준 캐시에 있으면로드 방법의 결과로 반환됩니다. 첫 번째 수준 캐시에 캐시 된 엔터티가 없으면 캐시 된 엔터티에 대해 두 번째 수준 캐시가 조회됩니다. 두 번째 레벨 캐시에 엔티티가 캐시 된 경우로드 메소드의 결과로 리턴됩니다. 그러나, 엔터티를 반환하기 전에 엔터티에 대한 다음로드 메서드 호출이 첫 번째 수준 캐시 자체에서 엔터티를 반환하므로 다시 두 번째 수준 캐시로 이동할 필요가 없도록 엔터티를 1 수준 캐시에 저장합니다. 엔티티가 1 레벨 캐시 및 2 레벨 캐시에서도 발견되지 않으면 데이터베이스 쿼리가 실행되고 엔티티는 응답으로 리턴되기 전에 두 캐시 레벨 모두에 저장됩니다.load() 방법.
1 차 캐시
최대 절전 모드는 마지막 가능한 순간까지 지속 컨텍스트 플러시를 지연 시키려고합니다. 이 기사 에서 설명했듯이이 전략은 전통적으로 트랜잭션 쓰기 숨김으로 알려져 있습니다.
쓰기 숨김은 논리적 또는 물리적 트랜잭션보다는 최대 절전 모드 플러시와 관련이 있습니다. 트랜잭션 중에 플러시가 여러 번 발생할 수 있습니다.
플러시 된 변경 사항은 현재 데이터베이스 트랜잭션에 대해서만 표시됩니다. 현재 트랜잭션이 커밋 될 때까지 다른 동시 트랜잭션에서 변경 내용을 볼 수 없습니다.
첫 번째 수준의 캐시로 인해 Hibernate는 여러 가지 최적화를 수행 할 수 있습니다.
2 차 캐시
적절한 캐싱 솔루션은 여러 Hibernate 세션에 걸쳐 있어야하므로 Hibernate가 추가 2 차 수준 캐시를 지원하는 이유입니다.
두 번째 수준 캐시는 SessionFactory 수명주기에 바인딩되므로 SessionFactory닫을 때만 (일반적으로 응용 프로그램이 종료 될 때) 소멸됩니다 . 두 번째 수준 캐시는 선택적 엔터티 캐싱 솔루션도 지원하지만 주로 엔터티 기반 지향입니다.
기본적으로 NHibernate는 세션 객체 기반의 1 차 캐싱을 사용합니다. 그러나 다중 서버 환경에서 실행중인 경우 첫 번째 레벨 캐시는 일부 성능 문제와 함께 확장 성이 떨어질 수 있습니다. 데이터가 여러 서버에 분산되어 있기 때문에 데이터베이스를 자주 방문해야하기 때문에 발생합니다. 다시 말해 NHibernate는 기본적이지 않은 정교한 In-process L1 캐시를 기본적으로 제공합니다. 그러나 캐싱 솔루션이 응용 프로그램 성능에 현저한 영향을 미쳐야하는 기능은 제공하지 않습니다.
따라서이 모든 문제의 문제는 세션 팩토리 객체와 관련된 L2 캐시를 사용하는 것입니다. 데이터베이스에 소요되는 시간이 단축되어 궁극적으로 앱 응답 시간이 늘어납니다.
두 번째 레벨 캐시에서 도메인 hbm 파일은 키를 변경할 수 있으며 값은 false 일 수 있습니다. 예를 들어,이 도메인 클래스에서 하루 중 일부 기간은 보편적 진리로 일정하게 유지됩니다. 따라서 응용 프로그램 전체에서 불변으로 표시 할 수 있습니다.