## SQLite入門與分析(二)---設計與概念(續) 寫在前面:本節討論事務,事務是DBMS最核心的技術之一.在計算機科學史上,有三位科學家因在數據庫領域的成就而獲ACM圖靈獎,而其中之一Jim Gray(曾任職微軟)就是因為在事務處理方面的成就而獲得這一殊榮,正是因為他,才使得OLTP系統在隨后直到今天大行其道.關于事務處理技術,涉及到很多,隨便就能寫一本書.在這里我只討論SQLite事務實現的一些原理,SQLite的事務實現與大型通用的DBMS相比,其實現比較簡單.這些內容可能比較偏于理論,但卻不難,也是理解其它內容的基礎.好了,下面開始第二節---事務. ###2、事務(Transaction) ####2.1、事務的周期(Transaction Lifecycles) 程序與事務之間有兩件事值得注意： （1） 哪些對象在事務下運行——這直接與API有關。 （2） 事務的生命周期，即什么時候開始，什么時候結束以及它在什么時候開始影響別的連接（這點對于并發性很重要）——這涉及到SQLite的具體實現。 一個連接（connection）可以包含多個(statement)，而且每個連接有一個與數據庫關聯的B-tree和一個pager。Pager在連接中起著很重要的作用，因為它管理事務、鎖、內存緩存以及負責崩潰恢復(crash recovery)。當你進行數據庫寫操作時，記住最重要的一件事：在任何時候，只在一個事務下執行一個連接。這些回答了第一個問題。 一般來說，一個事務的生命和statement差不多，你也可以手動結束它。默認情況下，事務自動提交，當然你也可以通過BEGIN..COMMIT手動提交。接下來就是鎖的問題。 ####2.2、鎖的狀態(Lock States) 鎖對于實現并發訪問很重要，而對于大型通用的DBMS，鎖的實現也十分復雜，而SQLite相對較簡單。通常情況下，它的持續時間和事務一致。一個事務開始，它會先加鎖，事務結束，釋放鎖。但是系統在事務沒有結束的情況下崩潰，那么下一個訪問數據庫的連接會處理這種情況。 在SQLite中有5種不同狀態的鎖，連接（connection）任何時候都處于其中的一個狀態。下圖顯示了相應的狀態以及鎖的生命周期。  關于這個圖有以下幾點值得注意： （1） 一個事務可以在UNLOCKED，RESERVED或EXCLUSIVE三種狀態下開始。默認情況下在UNLOCKED時開始。 （2） 白色框中的UNLOCKED, PENDING, SHARED和 RESERVED可以在一個數據庫的同一時存在。 （3） 從灰色的PENDING開始，事情就變得嚴格起來，意味著事務想得到排斥鎖(EXCLUSIVE)（注意與白色框中的區別）。 雖然鎖有這么多狀態，但是從體質上來說，只有兩種情況：讀事務和寫事務。 ####2.3、讀事務(Read Transactions) 我們先來看看SELECT語句執行時鎖的狀態變化過程，非常簡單：一個連接執行select語句，觸發一個事務，從UNLOCKED到SHARED，當事務COMMIT時，又回到UNLOCKED，就這么簡單。 考慮下面的例子(為了簡單，這里用了偽碼)： ~~~ db = open('foods.db') db.exec('BEGIN') db.exec('SELECT * FROM episodes') db.exec('SELECT * FROM episodes') db.exec('COMMIT') db.close() ~~~ 由于顯式的使用了BEGIN和COMMIT，兩個SELECT命令在一個事務下執行。第一個exec()執行時，connection處于SHARED，然后第二個exec()執行，當事務提交時，connection又從SHARED回到UNLOCKED狀態，如下： UNLOCKED→PENDING→SHARED→UNLOCKED 如果沒有BEGIN和COMMIT兩行時如下： UNLOCKED→PENDING→SHARED→UNLOCKED→PENDING→ SHARED→UNLOCKED ####2.4、寫事務（Write Transactions） 下面我們來考慮寫數據庫，比如UPDATE。和讀事務一樣，它也會經歷UNLOCKED→PENDING→SHARED，但接下來卻是灰色的PENDING， 2.4.1、The Reserved States 當一個連接（connection）向數據庫寫數據時，從SHARED狀態變為RESERVED狀態，如果它得到RESERVED鎖，也就意味著它已經準備好進行寫操作了。即使它沒有把修改寫入數據庫，也可以把修改保存到位于pager中緩存中（page cache）。 當一個連接進入RESERVED狀態，pager就開始初始化恢復日志（rollback journal）。在RESERVED狀態下，pager管理著三種頁面： (1) Modified pages：包含被B-樹修改的記錄，位于page cache中。 (2) Unmodified pages：包含沒有被B-tree修改的記錄。 (3) Journal pages：這是修改頁面以前的版本，這些并不存儲在page cache中，而是在B-tree修改頁面之前寫入日志。 Page cache非常重要，正是因為它的存在，一個處于RESERVED狀態的連接可以真正的開始工作，而不會干擾其它的（讀）連接。所以，SQLite可以高效的處理在同一時刻的多個讀連接和一個寫連接。 2.4.2 、The Pending States 當一個連接完成修改，就真正開始提交事務，執行該過程的pager進入EXCLUSIVE狀態。從RESERVED狀態，pager試著獲取PENDING鎖，一旦得到，就獨占它，不允許任何其它連接獲得PENDING鎖（PENDING is a gateway lock）。既然寫操作持有PENDING鎖，其它任何連接都不能從UNLOCKED狀態進入SHARED狀態，即沒有任何連接可以進入數據（no new readers, no new writers）。只有那些已經處于SHARED狀態的連接可以繼續工作。而處于PENDING狀態的Writer會一直等到所有這些連接釋放它們的鎖，然后對數據庫加EXCUSIVE鎖，進入EXCLUSIVE狀態，獨占數據庫(討論到這里，對SQLite的加鎖機制應該比較清晰了)。 2.4.3、The Exclusive State 在EXCLUSIVE狀態下，主要的工作是把修改的頁面從page cache寫入數據庫文件，這是真正進行寫操作的地方。 在pager寫入modified pages之前，它還得先做一件事：寫日志。它檢查是否所有的日志都寫入了磁盤，而這些通常位于操作的緩沖區中，所以pager得告訴OS把所有的文件寫入磁盤，這是由程序synchronous(通過調用OS的相應的API實現)完成的。 日志是數據庫進行恢復的惟一方法，所以日志對于DBMS非常重要。如果日志頁面沒有完全寫入磁盤而發生崩潰，數據庫就不能恢復到它原來的狀態，此時數據庫就處于不一致狀態。日志寫入完成后，pager就把所有的modified pages寫入數據庫文件。接下來就取決于事務提交的模式，如果是自動提交，那么pager清理日志，page cache，然后由EXCLUSIVE進入UNLOCKED。如果是手動提交，那么pager繼續持有EXCLUSIVE鎖和保存日志，直到COMMIT或者ROLLBACK。 總之，從性能方面來說，進程占有排斥鎖的時間應該盡可能的短，所以DBMS通常都是在真正寫文件時才會占有排斥鎖，這樣能大大提高并發性能。