[SPRING] 최대 절전 모드 + 스프링 캐싱 - 몇 가지 질문!

최대 절전 모드 + 스프링 캐싱 - 몇 가지 질문!

임씨는 스프링 3과 하이버 네이트 3.6으로 웹 애플리케이션을 개발하고있다. 지금은 Spring과 Hibernate로 캐싱하는 것이 어떻게 작동하는지 이해하려고 노력합니다. 나는 Hibernate로 캐싱에 대한 정보와 Spring에 관한 정보를 찾았고, 이제는 정보를 함께 가져 오려고합니다. 나는 두 프레임 워크에 대해 몇 가지 질문을하고 있으며, 이드는 여기에 열거 된 사실들이 맞는지 누군가가 대답하거나 말해 줄 수 있다면 기쁘다.

대부분의 경우, 짧은 대답 (예 / 아니오)이면 충분합니다. 이 목록은 다른 사람들에게 유용 할 수 있다고 생각합니다. 봄과 최대 절전 모드로 캐싱하는 방법을 이해하고 싶습니다.

일반

1) Hibernate는 1 차 캐시, 2 차 캐시, 질의 캐시

2) Spring 자체는 다음과 같은 캐싱 기능을 지원합니다.

1 차 수준 캐시

3) 1 차 레벨 캐시는 모든 Hibernate 어플리케이션의 일부입니다.

4) 1 차 수준 캐시는 모든 최대 절전 모드 세션에 대해 생성됩니다.

5) 1 차 캐시에 저장된 내용은 무엇입니까? 객체 또는 속성의 값만? 쿼리 및 그 결과?

2 차 수준 캐시

6) 발견 : 2 차 레벨 캐시는 응용 프로그램 당 한 번 사용됩니다. 그건 틀린가요? 그것은 sessionfactory 당 한 번 사용되지 않습니까? 및 : 여러 sessionfactorys = 가능한 여러 번째 2 수준 캐시?

7) 제 2 수준 캐시에 저장되는 것 : 내 의견으로는 객체 자체가 아니라 하나의 레코드에 속한 값입니다.

8) 2 차 수준 캐시의 한 레코드에서 값을 저장할 때 관련 키 값을 외래 키를 통해 연결된 개체에서 저장할 수 있습니까?

9) 2 레벨 캐시에서 한 객체의 값을 업데이트 할 때 캐시에 연결된 객체의 값을 캐시에서 업데이트 할 수 있습니까?

10) 개체의 값이 변경되면 어떻게 2 수준 캐시를 업데이트 할 수 있습니까? 플러시? 캐시의 일부만 업데이트하거나 전체 캐시를 업데이트해야합니까?

11) 2 차 수준 캐시는 어디에서 의미가 있으며 어디에서 그렇지 않습니까?

12) 캐시 모드 : 각 캐시 모드가 다른 캐시 전략을 제공합니까? 예를 들어 캐시 모드가 "읽기 전용"이면 데이터베이스와 캐시의 동기화가 필요하지 않습니다. 다른 캐시 모드가 동기화를 제공합니까? 동기화는 개발자 자신이 수행해야한다고 생각했습니다.

쿼리 캐시

13) Query Cache와 2nd Level Cache의 차이점은 무엇입니까? 내 의견으로는 : 쿼리 캐시 결과 집합은 저장되지만 값은 저장되지 않고 ID로 저장됩니다. 질의가 다시 사용되고 결과 세트가 여전히 "정확하다"면, id에 속한 값은 2 차 레벨 캐시에서 질의됩니다

14) 질의 캐시의 경우 2 차 수준 캐시를 사용해야 만합니까?

15) 쿼리 캐시는 어디에서 의미가 있으며 어디에 있지 않습니까?

봄

16) Spring은 메소드 캐싱보다 더 많은 캐싱 가능성을 제공합니까?

17) 메소드 캐싱이 최대 절전 캐싱에 연결되지 않음

18) 그러나 : 2 차 수준을 캐싱하는 방법은 ehcache (최대 절전 모드에서도 사용할 수 있음)

19) 데이터베이스 캐싱없이 메서드 캐싱을 사용할 수 있습니까?

혼란에 빠지다

20) ehcache를 2 단계 캐쉬로 사용하고 ehcache를 캐싱 메소드 캐싱으로 사용한다면 동일한 ehcache-instance를 사용할 수 있습니까? 무언가가 섞일 기회가 있습니까?

21) 1 차 캐시와 2 차 캐시를 사용할 때 혼란 스러울 수 있습니까? 데이터베이스를 질의 할 때 결과는 어디에서 왔는가? 1 차 또는 2 차 캐시? 1 차 캐시는 2 차 캐시에서 작동합니까?

22) 내가 언급 한 캐시를 사용하여 섞일 수있는 다른 것? :-)

어떤 질문이든 답해 주셔서 감사합니다! :-)

해결법

1. ==============================

   1.예.

   예.

   Spring 3.1은 메소드 주위의 주석에 기반한 새로운 캐싱 추상화를 도입했다.

   예.

   예, 어떤 주어진 순간에 수동으로 지울 수 있습니다.

   그것은 세션이 끝날 때까지 가져온 모든 객체의지도입니다. 동일한 객체를 ID로 두 번째로드하면 L1에서로드됩니다.

   맞습니다. 일반적으로 애플리케이션 (데이터베이스) 당 하나의 세션 팩토리가 있으므로 바로 가기입니다.

   L1에서와 같은 것들이지만, 그들은 더 오래 산다. L2는 일반적으로 산업 강도의 캐시에 의해 뒷받침되는 반면, L1은 단지지도 일뿐입니다 (스레드로부터 안전하지 않아도 됨). 느린로드 된 관계를 포함하여 전체 엔티티를 저장합니다.

   수동으로 L2를 관리하지는 않지만 자동으로 발생합니다.

   위 참조.

   위에서 보자 - Hibernate는 이것을 알아낼 것이다. 당신은 L2와 직접 상호 작용하지 않습니다.

   법안. 기본 키로 많은 양의 데이터를 읽고 읽기 - 쓰기 요소가 매우 높은 응용 프로그램에서 L2는 성능에 중요한 영향을 미칩니다.

   캐시 모드는 Hibernate가 캐싱과 무효화를위한 최상의 전략을 선택하도록 도와 준다. 예를 들어 캐시가 읽기 전용이라면, Hibernate는 그것을 무효화하지 않을 것이다 (또는 자주 그렇게하지 않을 것이다). 그러나 읽기 전용 캐시 (읽기 전용 엔티티)는 물론 모든 업데이트를 금지합니다.

   정확 하긴하지만 이것은 매우 광범위한 주제입니다. 특히 결과 집합은 여전히 ​​"올바른"부분입니다.

   예, L2 캐시가 없으면 쿼리 캐시는 의미가 없으므로 응용 프로그램의 속도가 크게 저하됩니다.

   일반적으로 동일한 쿼리를 여러 번 실행하고 쿼리 매개 변수의 유니버스가 낮은 경우 (쿼리 매개 변수의 각 집합에 대해 새 쿼리 캐시는 모든 레코드 ID가 결과로 만들어 짐) 어려운 질문입니다.

   아니요, Spring은 자신의 코드를위한 접착제입니다.

   Spring은 Hibernate에 링크되어 있지 않으므로 ...

   L2는 최대 절전 모드 개념입니다. 메소드를 캐시하려면 기본 캐시가 필요합니다. 그것이 EhCache가되게하십시오, 결코 신경 쓰지 마십시오. 물론 스레드로부터 안전해야합니다.

   Spring은 Hibernate와 아무런 관련이 없다. 데이터베이스와 아무 관련이없는 계산을 캐싱 할 수 있습니다.

   Hibernate와 동일한 CacheManager와 캐시 구성을 사용하여 배치를 쉽게 할 수 있습니다. 캐시 이름이 중복되지 않는 한 캐시 이름은 완전히 독립적이며 동일한 관리자 내에서 작업하는 것으로 생각됩니다.

   일부 추상화가 누출되지 않는 한 그들은 작동합니다 :-). 기본 키를 사용하여 쿼리하면 첫 번째 L1이 검사되고 (더 빠름) L2가 먼저 검사됩니다.

   위 참조, 추상화가 누출되는 경향이 있습니다. 그러나 최악의 문제는 당신이 데이터베이스를 변경할 때 일어나며 Hibernate는 그것에 대해 알지 못한다. 또한 적절한 복제없이 클러스터링하면 두통이 생길 수 있습니다. 그리고 가장 큰 문제는 - 종종 잘못된 캐싱이 실제로 애플리케이션 속도를 늦추는 것입니다 (쿼리 캐시가 가장 위험합니다).

2. ==============================

   2.Spring 및 2 차 레벨 캐시에 관해서는 2L 캐시에서 작동하는 데 도움이되는 멋진 오픈 소스 프로젝트가 있습니다.

   Spring 및 2 차 레벨 캐시에 관해서는 2L 캐시에서 작동하는 데 도움이되는 멋진 오픈 소스 프로젝트가 있습니다.

   예 : http://code.google.com/p/ehcache-spring-annotations/

   우리는 프로덕션 환경에서이를 사용하고 있으며 라이브를 훨씬 쉽게 만듭니다.

from https://stackoverflow.com/questions/5405417/caching-with-hibernate-spring-some-questions by cc-by-sa and MIT license