최대 절전 모드에서 낙관적 잠금에 관한 한 가지 질문이 있습니다. 최대 절전 모드로 낙관적 인 잠금 내부 깊숙한 시도하고 있지만 하나의 의심이있다. Hibernate는 버전 접근 방식 (정수 또는 타임 스탬프)을 사용하여 낙관적 잠금을 구현합니다. 구성하려면 @Version 주석 (또는 xml 구성)을 사용하고 버전 속성을 만들 수 있습니다. 다른 옵션은 optimistic-lock = "all"속성을 사용하여 버전을 지정하지 않고 구성하는 것입니다.기본적으로 최대 절전 모드에서의 낙관적 잠금
제 질문은 버전 지정 속성을 정의하지 않고 optimistic-lock 속성을 지정하지 않은 경우입니다.이 경우 전략은 최대 절전 모드를 사용합니까? Pessimistc Locking 나는 안된다고 확신한다. 그래서 낙천적 인 잠금이지만 어떻게해야할지 모르겠다.
감사합니다.
낙관적 잠금을 사용하도록 Hibernate를 구성하지 않으면, 잠금을 전혀 사용하지 않습니다. 따라서이 경우 마지막 업데이트가 항상 우선합니다.
Hibernate optimistic locking은 DBMS 트랜잭션 격리와 완전히 다르다는 것을 명심하자. Hibernate optimistic locking은 객체를 하나의 트랜잭션에로드하고 수정 한 다음 나중에 다른 트랜잭션에 저장하는 경우에만 작동합니다. 이 경우 낙관적 잠금은 다른 트랜잭션이 데이터베이스의 해당 개체를 중간에 변경하지 않았는지 확인합니다. 그러나 낙관적 인 잠금은 동시 트랜잭션의 격리에는 영향을 미치지 않으므로 트랜잭션 격리를 구현하기 위해 내부적으로 DBMS에서 사용되는 잠금 (낙관적 또는 비관적)은 최대 절전 모드 잠금이 설정되었는지 여부에 관계없이 여전히 작동합니다.
@axtavt 맞지 만, 최대 절전 모드가 낙관적 잠금을 구현하는 방법에 대한 질문은 @Version 열이 아닙니다. 사용할 수
오늘 네 OptimisticLockType 옵션 :
/**
* Perform no optimistic locking.
*/
NONE,
/**
* Perform optimistic locking using a dedicated version column.
*
* @see javax.persistence.Version
*/
VERSION,
/**
* Perform optimistic locking based on *dirty* fields as part of an expanded WHERE clause restriction for the
* UPDATE/DELETE SQL statement.
*/
DIRTY,
/**
* Perform optimistic locking based on *all* fields as part of an expanded WHERE clause restriction for the
* UPDATE/DELETE SQL statement.
*/
ALL
나는 이것이 원래의 질문에 대답하기에 충분하다고 생각합니다.