寫在前面:本節討論事務,事務是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通常都是在真正寫文件時纔會佔有排斥鎖，這樣能大大提高併發性能。