JBoss TreeCache에 대한 동시성 전략 설정 (2nd level Hibernate 캐시)

Question

JBoss EAP 4.3을 사용 중입니다.

내장 JBoss TreeCache를 Hibernate의 두 번째 레벨 캐시로 사용할 때 동시성 전략에 대한 다른 옵션을 찾고 있습니다. 나는 그것을 설정했고 캐시가 로그를 조사하여 작동하는지 확인했지만 동시성 전략이 실제로 사용되고 어떤 방식으로 작동하는지 확신 할 수 없습니다.

각 엔티티를 들어, 나는 @Cache 주석에 다음 "사용"값 중 하나를 설정할 수 있습니다 NONE, READ_ONLY, NONSTRICT_READ_WRITE, READ_WRITE, TRANSACTIONAL을. NONE, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE (또는 OPTIMISTIC 사용) : 한편

, 내 JBossTreeCache 구성 파일에 나는 전체 캐시에 대해 다음 중 하나에 IsolationLevel을 설정할 수 있습니다.

한 번에 하나씩 구성 옵션을 살펴볼 때 문서가 분명하지만 다른 옵션을 결합 할 때 어떤 일이 발생하는지 궁금합니다. 당신이 @Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL) 엔티티 설정하지만 JBossTreecache에 대한 IsolationLevel로 NONE를 구성하는 경우 예를 들어

은 어떻게됩니까?

는 또한 JBossTreeCache 만 NONE, READ_ONLY 및 TRANSACTIONAL 사용을 지원하는 것으로 생각하지만 IsolationLevel은 당신이 그들을 결합 할 수 있습니까? 예를 들어 NONSTRICT_READ_WRITE을 사용하면 어떻게됩니까?

날이를 정렬하는 데 도움 anyoone 수 ..

는 Alltogether 여기 × 6 다른 조합처럼이 있어야한다,하지만 그들 모두 의미가?

Answer 1

격리 수준은 까다로운 문제입니다. 당신이 @Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL) 엔티티 설정하지만 JBossTreecache에 대한 IsolationLevel로 NONE를 구성하는 경우 예를 들어

은 어떻게됩니까?

대부분 생산하기가 어려운 버그 ... 읽기 - 쓰기 캐시를 사용하면 기본적으로 분산 트랜잭션에서 '신중함'을 모두 지니고 있음을 이해해야합니다.

Ok : 약 조합 : 개체가 변경되지 않을 때 최대 절전 모드의 읽기 전용 캐시 설정을 사용해야합니다. 예를 들어, 국가 사전의 경우. 캐시 동시성 레벨 NONE 또는 READ_ONLY를 함께 사용해야합니다.

캐시 된 개체가 변경 될 때 엄격하지 않은 읽기 쓰기를 사용해야하지만 거의 발생하지 않으며 경쟁 조건이 적을 수 있습니다. 예를 들어 시간대 사전의 경우 시간대가 가끔씩 나타나거나 사라질 수 있지만 일년에 두 번 발생할 수 있습니다. 다시 말해 캐시 동시성 레벨 NONE 또는 READ_ONLY가 함께 사용되어야합니다.

지금, 더 흥미로운 조합입니다.

Transactional 캐시가 Hibernate에서 안전하지 않을 때, Hibernate는 캐시 갱신이 트랜잭션 적이라고 가정하지만이를 보장하지는 않는다. 따라서 반드시 외부 XA (분산 트랜잭션) 코디네이터를 사용해야하며, 실제로 무엇을하고 있는지 알지 못한다면 정말로 원하지 않을 것입니다. 대체로 평범한 서블릿 + Spring을 가지고 http://www.atomikos.com/과 같은 외부 트랜잭션 관리자를 사용할 수는 있지만 대부분 XA 관리자 지원을 위해 전체 EJB3 컨테이너를 사용해야 할 것이다. 분명히 캐시를 TRANSACTIONAL 사용해야합니다.

'READ_WRITE'는 흥미로운 조합입니다. 이 모드에서 Hibernate는 가벼운 XA 코디네이터로 작동하기 때문에 본격적인 외부 XA는 필요하지 않습니다. 어떻게 동작하는지에 대한 간단한 설명 :

1. 이 모드에서 Hibernate는 트랜잭션 자체를 관리한다. 모든 DB 작업은 트랜잭션 내부에 있어야하며 자동 커밋 모드는 작동하지 않습니다.
2. (트랜잭션 수명 동안 여러 번 나타날 수 있지만 일반적으로 커밋 바로 전에 발생한다) 최대 절전 모드는 세션을 거쳐 업데이트/삽입/삭제 된 개체를 검색한다. 그런 다음 이러한 개체는 먼저 데이터베이스에 저장되고 은 캐시에 잠겨 업데이트 된이므로 동시 트랜잭션 은을 업데이트하거나 읽을 수 없습니다.
3. 그런 다음 트랜잭션이 롤백되면 (명시 적으로 또는 일부 오류로 인해) 잠긴 개체가 캐시에서 제거되고 제거되므로 다른 트랜잭션이 해당 개체를 읽고 업데이트 할 수 있습니다.
4. 트랜잭션이 커밋되면 성공적으로 잠긴 개체가 해제되고 다른 스레드는 해당 개체를 읽고 쓸 수 있습니다.

   가능한 반복 읽기 위반 :

여기 좋은 점 몇 가지가 있습니다. 트랜잭션 A (tA)와 트랜잭션 B (tB)가 동시에 시작되고 두 객체 X, tA를로드 한 다음이 객체를 수정 한 다음 tA가 완료되었다고 가정 해보십시오. 스냅 샷 격리 (Oracle, PostgreSQL, FireBird)를 사용하는 많은 데이터베이스에서 tB가 객체 X를 다시 요청하면 트랜잭션 시작시와 동일한 객체 상태를 수신해야합니다. 그러나 READ_WRITE 캐시는이 조건을 위반할 수 있습니다. 스냅 샷 격리가 없습니다. Hibernate는 캐시 된 객체의 타임 스탬프를 사용하지만 타이머 해상도가 좋지 않은 OS (Windows의 경우 15.6ms)를 사용하여 문제를 해결하려고 시도하지만 일부 레이스가 빠져 나가도록 보장합니다.

가능한 낙관적 인 오래된 개체 버전 - Windows에서 작업하는 것이 매우 불행한 경우 오래된 개체 버전을 가져올 수 있으며 동일한 타임 스탬프로 여러 트랜잭션을 커밋 할 수 있습니다.