레코드 잠금에 관해서 우리 팀을 위해 권장되는 디자인 패턴을 제시하려고합니다. 일반적인 생각은 다음과 같습니다. 1. 사용자가 목록에서 레코드를 선택합니다. 2. 사용자 ID가 인 레코드를 잠급니다. 3. 잠긴 레코드 레코드를로드합니다 (잠금이 없으면 누군가가 나중에 이길 수 있습니다).분산 시스템 내 레코드 잠금에 대한 권장 사항 찾기
내가 누락되었거나이를 수행하는 유일한 방법 인 것처럼 보입니까? (우리의 경우 낙관적 인 잠금은 최종 사용자들에게는 성 가시고 혼란 스럽습니다. 편집은 종종 상당히 복잡합니다.)
솔루션 관리를 집중적으로 수행 할 수있는 세부 정보는 충돌 또는 연결 실패 후 잠금을 제거합니다. 이것이 바로 낙관적 잠금과 비관적 잠금 간의 절충점입니다. 낙관적 인 잠금이 실패 할 때 편집을 수동으로 병합 또는 다시 실행하면 비관적이고 지속적인 잠금 모델에서 충돌이 발생하면 스스로 두통을 낳습니다. (Pervasive 백업 회계 시스템 사용자를 지원하는 사람은 누구나 주어진 길이로 알려줍니다. 기회)
하나의 대답은 트랜잭션과 동시성을 관리하기 위해 RDBMS의 메커니즘을 사용하는 것입니다. SELECT FOR UPDATE 또는 사용자 환경과 격리 수준에 맞는 구문을 사용하여 레코드를 가져옵니다. 클라이언트 중 하나가 충돌하거나 연결이 끊어지면 트랜잭션이 롤백되고 잠금이 해제됩니다. 웹 또는 환경과 같은 비 연결 환경에서
연결이 손실 및 세션 시간 제한 자주 세션 기반 모델을 복구받을 곳도 일할 수 :이 경우 기록에 기존의 잠금을 취소따라서 세션이 만료되면 잠금이 해제됩니다. 크래시 및 클라이언트/연결 문제의 허용 오차가 발생한 후 수동으로 잠금을 제거 할 필요가 없습니다. 그래도 코드를 작성하는 데는 약간의 작업이 필요합니다.
좋습니다. 벨. 고마워. 잠금 시간 초과를 고려하지 않았습니다. ticketMaster와 같은 다른 시스템에 대해서 생각할 때 의미가 있습니다. – kdmurray