Locking

• 데이터를 읽거나 수정할 때 데이터에 표시하는 장금장치.

• 트랜잭션이 다루는 데이터를 다른 트랜잭션이 접근하지 못하도록 막아 대기 상태로 만듦.
  -> 다른 트랜잭션을 대기상태로 만드는 일: 응답시간에 영향을 줄 수 있기 때문에 최소화 해야한다.

• 락을 사용하면 데이터에 대한 갱신을 순차적으로 진행 할 수 있음 -> 갱신손실 문제를 해결할 수 있음. -> 일관성문제를 해결할 수 있음.

• shared lock을 걸어주면 lock X는 허용하지 않고, lock S의 요청은 허용한다.

• exclusive lock을 걸어두면 lock X, lock S 모두 허용하지 않는다.

• 매니저가 락을 승인하지 않으면 트랜잭션은 대기상태가 된다.

2단계 락킹 (2PL)

• 락을 걸고 해제하는 시점에 제한을 두지 않으면 두 개의 트랜젝션이 동시에 실행될때 일관성이 깨질 수 있다.
• 데이터에 lock을 걸었다 풀고 다시 거는 중간 과정에 lock의 해지 상태가 생기면서 다른 트랜젝션에게 중간 결과를 보일 수 있다.

1. 확장단계 growing phase
   • 트랜잭션이 필요한 lock을 획득하는 단계.
   • 이미 획득한 lock을 해제하지 않는다.
   • 트랜잭션이 lock 연산을 수행할 수 있으나 unlock연산은 수행할 수 없는 단계
2. 수축단계 shrinking phase
   • 트랜잭션이 lock을 해제하는 단계.
   • 새로운 락을 획득하지 않는다.
   • 트랜잭션이 unlock 연산을 수행할 수 있으나 lock 연산을 수행 할 수 없는 단계

• 모든 lock연산들이 unlock 연산보다 먼저 실행 되어야 함!
• 모든 직렬 가능한 스케줄들이 2PL을 준수하는 것은 아니다
  

ex) lock을 사용하였지만 2단계 locking 방법을 적용하지 않음.

• T1이 write 작업중인 중간데이터를 가져와 T2가 작업을하였음. T1이 쓰기 작업을 중일때는 일관성이 일시적으로 깨진 상태이므로 이상태의 중간데이터 값을 T2가 가져오면 안된다.

• 트랜잭션 수행중에는 잠시 일관성이 깨질 수 있다.

• 해결방법: 트랜잭션이 작https://nowes00.tistory.com/19업을 완료하기 전에 lock을 해제하면 안된다.

  • 앞으로 T1이 앞으로 B에 락을 걸 예정이므로 A에 걸었던 락을 미리 해제하면 안된다.
  • T1이 끝날때까지 A에 lock을 해제하면 안된다는 뜻인가?? 그러면 T1이 B에 접근하고 다른 곳에 다 접근을 끝낸다음에 다 unlock을 하라는 뜻?

• 장점: 데이터의 일관성을 유지할 수 있다. 직렬화를 보장.

• 단점: 두개 이상의 트랜잭션이 각각 자신의 데이터에 대하여 락을 획득하고 상대방에 데이터에 대하여 락을 요청하면 무한대기 상태에 빠질 수 있다. --> DeadLock(교착상태)

-> 근데 2PL을 사용하면 deadlock이 불가피 하니까 어쨋든 순차적으로 하게 되는거 아니야? 그러면 동시 접근 맞음?
참고