트랜잭션의 실행 순서를 강제로 제어 하여 하나의 트랜잭션이 수행하는 동안 특정 데이터 항목에 대해 다른 트랜잭션이 동시에 접근하지 못하도록 방지 하는 것 lock이 걸린 데이터는 lock을 실행한 트랜잭션만 독점적으로 접근 가능
비관적인 방법: 동시에 실행해도 괜찮은 작업도 동시에 실행하지 못 하게 막을 수도 있다.
사용 연산: lock, unlock
잠금의 종류
(s-lock)공유잠금: 데이터는 read 하는 연산시 하는 잠금 두 트렌젝션이 요청시 동시에 제공 가능
(x-lock)배타잠금: 데이터를 write 하는 연산시 하는 잠금 두 트랜젝션이 요청시 동시에 제공 불가능
한계: 아무 조건 없이 lock, unlock 연산을 사용한다면 직렬 가능한 스케줄을 완벽히 보장 할 수 없음 다음 사례와 같이 OS가 연산의 순서를 다르게 할 경우 결과가 달라질 수 있기 때문
대안책 2Pase Locking: lock, unlock 연산을 확장 단계 축소 단계로 나누어서 확장단계일 때는 lock만 축소단계일때는 unlock 연산만 사용 할 수 있게끔 하여 직렬 가능한 스케줄을 보장한다. (단 교착 상태는 방지 불가능 하여 발생시 하나의 트랜젝션 작업을 죽여버린다.)
타임스탬프(timestamp)
최대한 병행 수행을 보장하며 직렬 가능한 스케줄에 위배될 가능성이 있으면 실행 취소하는 기법 타임스탬프는 트랜잭션이 시작된 시점을 나타내며, 각 트랜잭션에 고유한 타임스탬프를 부여 이는 데이터베이스에서 레코드를 읽거나 쓸 때마다 해당 레코드에 대한 타임스탬프를 업데이트하며, 이를 통해 트랜잭션의 실행 순서를 결정하여 직렬 가능한 스케줄을 보
낙관적인 방법: 가급적 전부 실행 시키되 결과가 직렬 스케쥴을 위배했다면 rollback 하는 방식
타임스탬프 프로토콜 규칙
Thomas Write Rule: 더 이전의 타임스탬프를 가진 트랜잭션에 의해 작성된 레코드를 더 늦은 타임스탬프를 가진 트랜잭션이 덮어쓰려고 하면, 이를 무시합니다. 이로 인해 더 이전의 변경 사항이 무효화되는 것을 방지합니다.
Wait-Die and Wound-Wait Schemes: 이는 타임스탬프가 충돌하는 트랜잭션에 대해 어떻게 처리할지를 결정합니다. Wait-Die 스키마에서는 더 이전의 타임스탬프를 가진 트랜잭션을 기다리게 하고, Wound-Wait 스키마에서는 더 이전의 타임스탬프를 가진 트랜잭션을 중단시킵니다.
