一、概述：
在SQLite中，鎖和並發控制機制都是由pager_module模塊負責處理的，如ACID(Atomic, Consistent, Isolated, and Durable)。在含有數據修改的事務中，該模塊將確保或者所有的數據修改全部提交，或者全部回滾。與此同時，該模塊還提供了一些磁盤文件的內存Cache功能。
事實上，pager_module模塊並不關心數據庫存儲的細節，如B-Tree、編碼方式、索引等，它只是將其視為由統一大小(通常為1024字節)的數據塊構成的單一文件，其中每個塊被稱為一個頁(page)。在該模塊中頁的起始編號為1，即第一個頁的索引值是1，其後的頁編號以此類推。
二、文件鎖：
在SQLite的當前版本中，主要提供了以下五種方式的文件鎖狀態。
1). UNLOCKED：
文件沒有持有任何鎖，即當前數據庫不存在任何讀或寫的操作。其它的進程可以在該數據庫上執行任意的讀寫操作。此狀態為缺省狀態。
2). SHARED：
在此狀態下，該數據庫可以被讀取但是不能被寫入。在同一時刻可以有任意數量的進程在同一個數據庫上持有共享鎖，因此讀操作是並發的。換句話說，只要有一個或多個共享鎖處於活動狀態，就不再允許有數據庫文件寫入的操作存在。
3). RESERVED：
假如某個進程在將來的某一時刻打算在當前的數據庫中執行寫操作，然而此時只是從數據庫中讀取數據，那麼我們就可以簡單的理解為數據庫文件此時已經擁有了保留鎖。當保留鎖處於活動狀態時，該數據庫只能有一個或多個共享鎖存在，即同一數據庫的同一時刻只能存在一個保留鎖和多個共享鎖。在Oracle中此類鎖被稱之為預寫鎖，不同的是Oracle中鎖的粒度可以細化到表甚至到行，因此該種鎖在Oracle中對並發的影響程序不像SQLite中這樣大。
4). PENDING：
PENDING鎖的意思是說，某個進程正打算在該數據庫上執行寫操作，然而此時該數據庫中卻存在很多共享鎖(讀操作)，那麼該寫操作就必須處於等待狀態，即等待所有共享鎖消失為止，與此同時，新的讀操作將不再被允許，以防止寫鎖饑餓的現象發生。在此等待期間，該數據庫文件的鎖狀態為PENDING，在等到所有共享鎖消失以後，PENDING鎖狀態的數據庫文件將在獲取排他鎖之後進入EXCLUSIVE狀態。
5). EXCLUSIVE：
在執行寫操作之前，該進程必須先獲取該數據庫的排他鎖。然而一旦擁有了排他鎖，任何其它鎖類型都不能與之共存。因此，為了最大化並發效率，SQLite將會最小化排他鎖被持有的時間總量。
最後需要說明的是，和其它關系型數據庫相比，如MySQL、Oracle等，SQLite數據庫中所有的數據都存儲在同一文件中，與此同時，它卻僅僅提供了粗粒度的文件鎖，因此，SQLite在並發性和伸縮性等方面和其它關系型數據庫還是無法比擬的。由此可見，SQLite有其自身的適用場景，就如在本系列開篇中所說，它和其它關系型數據庫之間的互換性還是非常有限的。
三、回滾日志：
當一個進程要改變數據庫文件的時候，它首先將未改變之前的內容記錄到回滾日志文件中。如果SQLite中的某一事務正在試圖修改多個數據庫中的數據，那麼此時每一個數據庫都將生成一個屬於自己的回滾日志文件，用於分別記錄屬於自己的數據改變，與此同時還要生成一個用於協調多個數據庫操作的主數據庫日志文件，在主數據庫日志文件中將包含各個數據庫回滾日志文件的文件名，在每個回滾日志文件中也同樣包含了主數據庫日志文件的文件名信息。然而對於無需主數據庫日志文件的回滾日志文件，其中也會保留主數據庫日志文件的信息，只是此時該信息的值為空。
我們可以將回滾日志視為"HOT"日志文件，因為它的存在就是為了恢復數據庫的一致性狀態。當某一進程正在更新數據庫時，應用程序或OS突然崩潰，這樣更新操作就不能順利完成。因此我們可以說"HOT"日志只有在異常條件下才會生成，如果一切都非常順利的話，該文件將永遠不會存在。
四、數據寫入：
如果某一進程要想在數據庫上執行寫操作，那麼必須先獲取共享鎖，在共享鎖獲取之後再獲取保留鎖。因為保留鎖則預示著在將來某一時刻該進程將會執行寫操作，所以在同一時刻只有一個進程可以持有一把保留鎖，但是其它進程可以繼續持有共享鎖以完成數據讀取的操作。如果要執行寫操作的進程不能獲取保留鎖，那麼這將說明另一進程已經獲取了保留鎖。在此種情況下，寫操作將失敗，並立即返回SQLITE_BUSY錯誤。在成功獲取保留鎖之後，該寫進程將創建回滾日志。
在對任何數據作出改變之前，寫進程會將待修改頁中的原有內容先行寫入回滾日志文件中，然而，這些數據發生變化的頁起初並不會直接寫入磁盤文件，而是保留在內存中，這樣其它進程就可以繼續讀取該數據庫中的數據了。
或者是因為內存中的cache已滿，或者是應用程序已經提交了事務，最終，寫進程將數據更新到數據庫文件中。然而在此之前，寫進程必須確保沒有其它的進程正在讀取數據庫，同時回滾日志中的數據確實被物理的寫入到磁盤文件中，其步驟如下：
1). 確保所有的回滾日志數據被物理的寫入磁盤文件，以便在出現系統崩潰時可以將數據庫恢復到一致的狀態。
2). 獲取PENDING鎖，再獲取排他鎖，如果此時其它的進程仍然持有共享鎖，寫入線程將不得不被掛起並等待直到那些共享鎖消失之後，才能進而得到排他鎖。
3). 將內存中持有的修改頁寫出到原有的磁盤文件中。
如果寫入到數據庫文件的原因是因為cache已滿，那麼寫入進程將不會立刻提交，而是繼續對其它頁進行修改。但是在接下來的修改被寫入到數據庫文件之前，回滾日志必須被再一次寫到磁盤中。還要注意的是，寫入進程獲取到的排他鎖必須被一直持有，直到所有的改變被提交時為止。這也意味著，從數據第一次被刷新到磁盤文件開始，直到事務被提交之前，其它的進程不能訪問該數據庫。
當寫入進程准備提交時，將遵循以下步驟：
4). 獲取排他鎖，同時確保所有內存中的變化數據都被寫入到磁盤文件中。
5). 將所有數據庫文件的變化數據物理的寫入到磁盤中。
6). 刪除日志文件。如果在刪除之前出現系統故障，進程在下一次打開該數據庫時仍將基於該HOT日志進行恢復操作。因此只有在成功刪除日志文件之後，我們才可以認為該事務成功完成。
7). 從數據庫文件中刪除所有的排他鎖和PENDING鎖。
一旦PENDING鎖被釋放，其它的進程就可以開始再次讀取數據庫了。
如果一個事務中包含多個數據庫的修改，那麼它的提交邏輯將更為復雜，見如下步驟：
4). 確保每個數據庫文件都已經持有了排他鎖和一個有效的日志文件。
5). 創建主數據庫日志文件，同時將每個數據庫的回滾日志文件的文件名寫入到該主數據庫日志文件中。
6). 再將主數據庫日志文件的文件名分別寫入到每個數據庫回滾日志文件的指定位置中。
7). 將所有的數據庫變化持久化到數據庫磁盤文件中。
8). 刪除主日志文件，如果在刪除之前出現系統故障，進程在下一次打開該數據庫時仍將基於該HOT日志進行恢復操作。因此只有在成功刪除主日志文件之後，我們才可以認為該事務成功完成。
9). 刪除每個數據庫各自的日志文件。
10).從所有數據庫中刪除掉排他鎖和PENDING鎖。
最後需要說明的是，在SQLite2中，如果多個進程正在從數據庫中讀取數據，也就是說該數據庫始終都有讀操作發生，即在每一時刻該數據庫都持有至少一把共享鎖，這樣將會導致沒有任何進程可以執行寫操作，因為在數據庫持有讀鎖的時候是無法獲取寫鎖的，我們將這種情形稱為"寫饑餓"。在SQLite3中，通過使用PENDING鎖則有效的避免了"寫饑餓"情形的發生。當某一進程持有PENDING鎖時，已經存在的讀操作可以繼續進行，直到其正常結束，但是新的讀操作將不會再被SQLite接受，所以在已有的讀操作全部結束後，持有PENDING鎖的進程就可以被激活並試圖進一步獲取排他鎖以完成數據的修改操作。
五、SQL級別的事務控制：
SQLite3在實現上確實針對鎖和並發控制做出了一些精巧的變化，特別是對於事務這一SQL語言級別的特征。在缺省情況下，SQLite3會將所有的SQL操作置於antocommit模式下，這樣所有針對數據庫的修改操作都會在SQL命令執行結束後被自動提交。在SQLite中，SQL命令"BEGIN TRANSACTION"用於顯式的聲明一個事務，即其後的SQL語句在執行後都不會自動提交，而是需要等到SQL命令"COMMIT"或"ROLLBACK"被執行時，才考慮提交還是回滾。由此可以推斷出，在BEGIN命令被執行後並沒有立即獲得任何類型的鎖，而是在執行第一個SELECT語句時才得到一個共享鎖，或者是在執行第一個DML語句時才獲得一個保留鎖。至於排它鎖，只有在數據從內存寫入磁盤時開始，直到事務提交或回滾之前才能持有排它鎖。
如果多個SQL命令在同一個時刻同一個數據庫連接中被執行，autocommit將會被延遲執行，直到最後一個命令完成。比如，如果一個SELECT語句正在被執行，在這個命令執行期間，需要返回所有檢索出來的行記錄，如果此時處理結果集的線程因為業務邏輯的需要被暫時掛起並處於等待狀態，而其它的線程此時或許正在該連接上對該數據庫執行INSERT、UPDATE或DELETE命令，那麼所有這些命令作出的數據修改都必須等到SELECT檢索結束後才能被提交。
這是該系列中最後一篇關於SQLite理論與應用方面的博客了，後面將發布兩篇關於如何利用SQLite編程的博客，其中還將包含四個典型的應用代碼示例，望大家繼續保持關注。
