Schedule must be Serializable and Recoverable✨

Concurrency Control Scheme

trade-off: amount of Concurrency <-> amount of Overhead.

일반적인 경우 동시성으로 인해 throughput이 더 높아지긴 하지. 근데 그로 인해 발생하는 오버헤드도 있다는 거. -> 보통 lock 과정에서 발생

Lock Based Protocol

1) Exclusive mode: lock-X(A)

read / write 둘 다 가능

2) Shared mode: lock-S(A)

read 만 가능.

lock-compatibility matrix

"grant" lock request.

💡 주의 shared lock 끼리는 서로 다른 transaction 에서도 동시에 lock 을 걸 수 있다는 점!
exclusive lock 이 껴있으면 상대 lock이 해제될 때까지 기다려야 함.
-> 보통 이건 잘 아는데, 문제는 shared lock으로 잡아둔다고 해서 다른 shared lock이 그걸 해제될때까지 기다릴 필요는 없다는 걸 인지하느냐는 거지 (난 못했음, 따라서 기록함..ㅜ)

serializability?

not sufficient to guarantee serializability ㅠㅠ
그래서 뭐가 나왔다?

Two-Phase Locking Protocol

a.k.a 2PL

Phase 1: Growing Phase

• transaction may obtain locks
  - can acquire a lock-S or lock-X on item
  - can convert a lock-S to a lock-X (upgrade)
• transaction may not release locks

Phase 2: Shrink Phase

• transaction may release locks
  - can release a lock-S or lock-X on item
  - can convert a lock-S to a lock-X (upgrade)
• transaction may not obtain locks

Properties

• The protocol assures (conflict) serializability
• 2PL does not ensure freedom from deadlocks
• starvation also possible
• cascading rollback is possible under 2PL

Strict 2PL

• A transaction must hold all its exclusive locks until it commits/aborts
• Avoids cascading roll-back

Rigorous 2PL

• all locks are held until commit/abort
• transactions can be serialized in the order in which they commit

둘다 한국말로는 엄격한 이라는 뜻인데, rigorous 가 shared locks 까지 붙잡고 있어서 더 강한 느낌이다.

---

추후 보충 예정 :)