2PL是併發控制理論的一種實現方式

Transaction Locks

通過Lock來保證所有的execution schdule是serializable

lock manager管理lock的分配與釋放
DBMS's lock-table 不需要持久化

• Lock：當有transaction需要修改一個tuple，lock manager將rid塞到佇列中，那麼其他transaction就不能去獲取這個tuple
• Latch：在B+樹index，光是單純的使用lock並不能保證併發的正確性，如果沒有latch，中間internal node會被修改，那麼會出錯

非兩階段鎖任然不能夠保證serializable

Two-Phase Locking

• 2PL是消極的，2PL會涉及級聯回滾問題？
  
  2PL會有限制併發，dirty read(也就是讀到了還未commit的資料)，dealock(即使是strong strict 2PL也不能解決deadlock)的問題,並且存在2PL並不能夠允許所有的serializable都能夠執行。strong strict 2PL 是指在commit或者abort的時候release lock，它能夠防止級聯終止
  
  

• 2PL能夠在一個transaction的所有queries執行之前，動態的決定是否一個transaction能夠訪問一個DBMS的物件

• 階段一：Growing：

  向lock manager獲取鎖。lock manager決定是否授予lock

• 階段二：Shrinking：當一個transaction歸還了第一個lock，那麼它就進入了Shrinking階段，它只能夠去release lock，而不能夠去acquire lock
  前後兩句話沒有關係吧？
  

DeadLock Handling

有兩種處理2PL中的deadlock

deadlock detection

通過wait-for graph檢測deadlock?
回滾事務還分成: Completely，Minimally

對於deadlock的檢測，這裡存在一種檢測頻率與陷入deadlock的txn的時間長短之間權衡，

Deadlock Prevention

不論是wait-die還是wound-wait，都是保證了只有一個方向會wait。因為沒有雙向的wait，所以可以避免deadlock

對於abort的young transaction，在restart時賦予其原來abort之前的priority，這樣可以防止飢餓

Lock Granularities

存在著一種在並行性與系統開銷之間的權衡
intention lock增加了並行性
Intention lock的存在目的：如果一個transaction需要對一個table加鎖，那麼它就是需要檢測這個table的每一個tuple，但是這樣花銷很大，這時候可以在其它transaction對這個table的tuple加lock時，給這個table加一個intention lock。
SIX是指給table加上S-Lock，給其中某個tuple加上X-Lock
IX與IX為什麼可以相容？

對tuple加鎖時，也需要對table加一定的鎖

low-level lock太多，lock escalation會將直接將這些底層鎖換成一個higher lock

一般來說，在使用DBMS時，不用顯示的加鎖

給整個資料庫備份的時候，為了使得所有的table拿到同一個時間的資料，那麼需要給整個資料庫加一個S-lock