낙관적 잠금 및 전체 테이블 잠금

Question

우리는 잠시 동안 낙관적 잠금 예외를받는 시스템을 가지고 있습니다. 우리는 코드에서이 문제를 해결했지만 JPA 2를 살펴본 후이를 처리하기 위해 주석 (@Version)이 있음을 확인했습니다.
우리는 테이블에 대해 둘 이상의 트랜잭션이 작동하고 있으며 전체 테이블 잠금을 사용하면 변경 사항이 동일한 레코드에 적용되지 않았더라도 낙관적 인 잠금 예외가 발생합니다.

우리는 JBoss 4.2 서버에서 최대 절전 모드를 사용하고 있으며 데이터베이스는 MySQL 또는 SQL Server 일 수 있습니다.

대신 @Version을 사용하도록 변경하면 두 데이터베이스에서 행 잠금이 적용됩니까? 아니면 전체 테이블 잠금으로 인해 낙관적 인 잠금 예외가 발생할 수 있습니까?

편집 : 우리가 실제로 참조하는 것은 낙관적 잠금 오류가 아니라 교착 상태
:

SQLServerException : 트랜잭션 와 잠금 리소스를 다른 프로세스를 교착 및 교착 상태로 선택되었습니다 희생자. 트랜잭션을 재실행하십시오.

코드에서이 문제를 처리하지만 @Version이이 경우 도움이 될지 궁금합니다.
적어도 하나의 경우에이 교착 상태는 두 개의 클라이언트가 자신의 데이터로 작업하는 테이블 잠금에 의해 발생합니다.

Answer 1

SQL 문에 따라 다릅니다. 어떤 이유로 든 트랜잭션이 필요한 자원에 대한 잠금을 확보하지 못할 때마다 + 관적 잠금이 _ 생합니다. 테이블 잠금 또는 행 잠금으로 인해 발생할 수 있습니다. 그건 중요하지 않아.

테이블 잠금이 필요한 SQL 쿼리를 실행중인 경우에는 버전 필드를 사용할 필요가 없습니다. 기본적으로 MS SQL Server는 행 잠금을 사용합니다. 따라서 작은 테이블이나 기본 키가 없거나 SQL Server가 쿼리에서 테이블 잠금을 사용하는 다른 이유가있을 수 있습니다.

테이블 잠금을 생성하고 조정하는 쿼리를 조사해야합니다. 가끔씩 잠금이 발생하여 응용 프로그램에서 처리해야합니다.

Answer 2

가능한 중복 : Optimistic vs. Pessimistic locking

낙관적 잠금 예외는 거의 항상 상태 동시성 문제입니다. 예를 들어, 두 스레드가 정확히 동일한 엔티티를로드하고 객체를 병렬로 변경 한 다음 저장합니다. 트랜잭션 (테이블 또는 행 잠금)에 관계없이에 관계없이이 문제가 발생하면 낙관적 인 잠금 예외가 발생합니다 (참조 된 질문 참조).

낙천적 인 잠김 예외가있는 @Version을 얻는 것에 충격을 받았습니다. 어쨌든 당신은 진짜 RDBMS OCC error을 얻고 있습니다. 그러나 나는 그것을 의심합니다. 가장 가능성있는 일은 @Version을 지정하지 않았으므로 전체 객체가 행과 비교되는 경우 행에 대한 변경으로 인해 낙관적 잠금 예외가 발생합니다. 추측 할 필요가 없도록 예외에 예외를 추가하십시오.