封鎖機制

封鎖機制
10.2.1 封鎖及鎖的類型
封鎖機制是併發控制的主要手段。封鎖是使事務對它要操做的數據有必定的控制能力。封鎖具備3個環節：第一個環節是申請加鎖，即事務在操做前要對它欲使用的數據提出加鎖請求；第二個環節是得到鎖，即當條件成熟時，系統容許事務對數據加鎖，從而事務得到數據的控制權；第三個環節是釋放鎖，即完成操做後事務放棄數據的控制權。爲了達到封鎖的目的，在使用時事務應選擇合適的鎖，並要聽從必定的封鎖協議。

基本的封鎖類型有兩種：排它鎖(Exclusive Locks，簡稱X鎖)和共享鎖(Share Locks，簡稱S鎖)。

(1)排它鎖

排它鎖也稱爲獨佔鎖或寫鎖。一旦事務T對數據對象A加上排它鎖(X鎖)，則只容許T讀取和修改A，其餘任何事務既不能讀取和修改A，也不能再對A加任何類型的鎖，直到T釋放A上的鎖爲止。

(2)共享鎖

共享鎖又稱讀鎖。若是事務T對數據對象A加上共享鎖(S鎖)，其餘事務對A只能再加S鎖，不能加X鎖，直到事務T釋放A上的S鎖爲止。

10.2.2 封鎖協議
簡單地對數據加X鎖和S鎖並不能保證數據庫的一致性。在對數據對象加鎖時，還須要約定一些規則。例如，什麼時候申請X鎖或S鎖、持鎖時間、什麼時候釋放等。這些規則稱爲封鎖協議(Locking Protocol)。對封鎖方式規定不一樣的規則，就造成了各類不一樣的封鎖協議。封鎖協議分三級，各級封鎖協議對併發操做帶來的丟失修改、不可重複讀取和讀「髒」數據等不一致問題，能夠在不一樣程度上予以解決。

(1)一級封鎖協議

一級封鎖協議是：事務T在修改數據以前必須先對其加X鎖，直到事務結束才釋放。

根據該協議要求，將表10.1種的任務T一、T2做爲事務,用A表示庫存,從新執行各操做的過程見表過程見表10.4。

表10.4 遵循一級封鎖協議的事務執行過程

可見，一級封鎖協議可有效地防止「丟失更新」，並可以保證事務T的可恢復性。可是，因爲一級封鎖沒有要求對讀數據進行加鎖，因此不能保證可重複讀和不讀「髒」數據。表10.5所示的操做過程聽從一級封鎖協議，但仍然發生了讀「髒」數據錯誤。讀者能夠用相似的操做實例，便會發現一級封鎖協議也不能避免不可重複讀的錯誤。

表10.5 聽從一級封鎖協議發生的讀「髒」數據過程

(2)二級封鎖協議

二級封鎖協議是：事務T對要修改數據必須先加X鎖，直到事務結束才釋放X鎖；對要讀取的數據必須先加S鎖，讀完後便可釋放S鎖。

二級封鎖協議不但可以防止丟失修改，還可進一步防止讀「髒」數據。可是因爲二級封鎖協議對數據讀完後便可釋放S鎖，因此不能避免「不可重複讀」錯誤。例如，表10.6所示的併發操做執行過程，聽從二級封鎖協議，但發生了「不可重複讀」錯誤。

表10.6 聽從二級封鎖協議發生的「不可重複讀」的過程

(3)三級封鎖協議

三級封鎖協議是事務T在讀取數據以前必須先對其加S鎖，在要修改數據以前必須先對其加X鎖，直到事務結束後才釋放全部鎖。

因爲三級封鎖協議強調即便事務讀完數據A以後也不釋放S鎖，從而使得別的事務沒法更改數據A。三級封鎖協議不但防止了丟失修改和不讀「髒」數據，並且防止了不可重複讀。

10.2.3 封鎖出現的問題及解決方法
事務使用封鎖機制後，會產生活鎖、死鎖等問題，DBMS必須妥善地解決這些問題，才能保障系統的正常運行。

1.活鎖

若是事務T1封鎖了數據R，T2事務又請求封鎖R，因而T2等待。T3也請求封鎖R，當T1釋放了R上的封鎖以後系統首先批准了T3的要求，T2仍然等待。而後T4又請求封鎖R，當T3釋放了R上的封鎖以後系統又批准了T4的請求，……，T2有可能永遠等待。這種在多個事務請求對同一數據封鎖時，使某一用戶老是處於等待的情況稱爲活鎖。

解決活鎖問題的方法是採用先來先服務。即對要求封鎖數據的事務排隊，使前面的事務先得到數據的封鎖權。

2.死鎖

若是事務T1和T2都須要數據Rl和R2，操做時Tl封鎖了數據R1，T2封鎖了數據R2；而後T1又請求封鎖R2，T2又請求封鎖Rl；因T2已封鎖了R2，故T1等待T2釋放R2上的鎖。同理，因T1已封鎖了R1，故T2等待T1釋放R1上的鎖。因爲Tl和T2都沒有得到所有須要的數據，因此它們不會結束，只能繼續等待。這種多事務交錯等待的僵持局面稱爲死鎖。

數據庫中解決死鎖問題主要有兩類方法：一類方法是採用必定措施來預防死鎖的發生；另外一類方法是容許發生死鎖，而後採用必定手段按期診斷系統中有無死鎖，如有則解除之。

通常來說，死鎖是不可避免的。DBMS的併發控制子系統一旦檢測到系統中存在死鎖，就要設法解除。一般採用的方法是選擇一個處理死鎖代價最小的事務，將其撤消，釋放此事務持有的全部的鎖，使其餘事務得以繼續運行下去。固然，對撤消的事務所執行的數據修改操做必須加以恢復。

10.2.3 封鎖的粒度
封鎖粒度(Granularity)是指封鎖對象的大小。封鎖對象能夠是邏輯單元，也能夠是物理單元。以關係數據庫爲例，封鎖對象能夠是屬性值、屬性值的集合、元組、關係、直至整個數據庫；也能夠是一些物理單元，例如頁(數據頁或索引項)、塊等。封鎖粒度與系統的併發度和併發控制的開銷密切相關。封鎖的粒度越小，併發度越高，系統開銷也越大；封鎖的粒度越大，併發度越低，系統開銷也越小。

一個系統應同時支持多種封鎖粒度供不一樣的事務選擇，這種封鎖方法稱爲多粒度封鎖 (Multiple Granularity Locking)。選擇封鎖粒度時應該綜合考慮封鎖開銷和併發度兩個因素，選擇適當的封鎖粒度以求得最優的效果。一般，須要處理大量元組的事務能夠以關係爲封鎖粒度；須要處理多個關係的大量元組的事務能夠以數據庫爲封鎖粒度；而對於一個處理少許元組的用戶事務，以元組爲封鎖粒度比較合適。
轉載於：https://blog.csdn.net/xijiaoda_liuhao/article/details/8444443