一、概述：

    在SQLite中，鎖和并發(fā)控制機(jī)制都是由pager_module模塊負(fù)責(zé)處理的，如ACID(Atomic, Consistent, Isolated, and Durable)。在含有數(shù)據(jù)修改的事務(wù)中，該模塊將確?；蛘咚械臄?shù)據(jù)修改全部提交，或者全部回滾。與此同時(shí)，該模塊還提供了一些磁盤文件的內(nèi)存Cache功能。
    事實(shí)上，pager_module模塊并不關(guān)心數(shù)據(jù)庫存儲(chǔ)的細(xì)節(jié)，如B-Tree、編碼方式、索引等，它只是將其視為由統(tǒng)一大小(通常為1024字節(jié))的數(shù)據(jù)塊構(gòu)成的單一文件，其中每個(gè)塊被稱為一個(gè)頁(page)。在該模塊中頁的起始編號(hào)為1，即第一個(gè)頁的索引值是1，其后的頁編號(hào)以此類推。
   
二、文件鎖：

    在SQLite的當(dāng)前版本中，主要提供了以下五種方式的文件鎖狀態(tài)。
    1). UNLOCKED：
    文件沒有持有任何鎖，即當(dāng)前數(shù)據(jù)庫不存在任何讀或?qū)懙牟僮?。其它的進(jìn)程可以在該數(shù)據(jù)庫上執(zhí)行任意的讀寫操作。此狀態(tài)為缺省狀態(tài)。
    2). SHARED：
    在此狀態(tài)下，該數(shù)據(jù)庫可以被讀取但是不能被寫入。在同一時(shí)刻可以有任意數(shù)量的進(jìn)程在同一個(gè)數(shù)據(jù)庫上持有共享鎖，因此讀操作是并發(fā)的。換句話說，只要有一個(gè)或多個(gè)共享鎖處于活動(dòng)狀態(tài)，就不再允許有數(shù)據(jù)庫文件寫入的操作存在。
    3). RESERVED：
    假如某個(gè)進(jìn)程在將來的某一時(shí)刻打算在當(dāng)前的數(shù)據(jù)庫中執(zhí)行寫操作，然而此時(shí)只是從數(shù)據(jù)庫中讀取數(shù)據(jù)，那么我們就可以簡單的理解為數(shù)據(jù)庫文件此時(shí)已經(jīng)擁有了保留鎖。當(dāng)保留鎖處于活動(dòng)狀態(tài)時(shí)，該數(shù)據(jù)庫只能有一個(gè)或多個(gè)共享鎖存在，即同一數(shù)據(jù)庫的同一時(shí)刻只能存在一個(gè)保留鎖和多個(gè)共享鎖。在Oracle中此類鎖被稱之為預(yù)寫鎖，不同的是Oracle中鎖的粒度可以細(xì)化到表甚至到行，因此該種鎖在Oracle中對(duì)并發(fā)的影響程序不像SQLite中這樣大。
    4). PENDING：
    PENDING鎖的意思是說，某個(gè)進(jìn)程正打算在該數(shù)據(jù)庫上執(zhí)行寫操作，然而此時(shí)該數(shù)據(jù)庫中卻存在很多共享鎖(讀操作)，那么該寫操作就必須處于等待狀態(tài)，即等待所有共享鎖消失為止，與此同時(shí)，新的讀操作將不再被允許，以防止寫鎖饑餓的現(xiàn)象發(fā)生。在此等待期間，該數(shù)據(jù)庫文件的鎖狀態(tài)為PENDING，在等到所有共享鎖消失以后，PENDING鎖狀態(tài)的數(shù)據(jù)庫文件將在獲取排他鎖之后進(jìn)入EXCLUSIVE狀態(tài)。
    5). EXCLUSIVE：
    在執(zhí)行寫操作之前，該進(jìn)程必須先獲取該數(shù)據(jù)庫的排他鎖。然而一旦擁有了排他鎖，任何其它鎖類型都不能與之共存。因此，為了最大化并發(fā)效率，SQLite將會(huì)最小化排他鎖被持有的時(shí)間總量。
   
    最后需要說明的是，和其它關(guān)系型數(shù)據(jù)庫相比，如MySQL、Oracle等，SQLite數(shù)據(jù)庫中所有的數(shù)據(jù)都存儲(chǔ)在同一文件中，與此同時(shí)，它卻僅僅提供了粗粒度的文件鎖，因此，SQLite在并發(fā)性和伸縮性等方面和其它關(guān)系型數(shù)據(jù)庫還是無法比擬的。由此可見，SQLite有其自身的適用場(chǎng)景，就如在本系列開篇中所說，它和其它關(guān)系型數(shù)據(jù)庫之間的互換性還是非常有限的。

三、回滾日志：

    當(dāng)一個(gè)進(jìn)程要改變數(shù)據(jù)庫文件的時(shí)候，它首先將未改變之前的內(nèi)容記錄到回滾日志文件中。如果SQLite中的某一事務(wù)正在試圖修改多個(gè)數(shù)據(jù)庫中的數(shù)據(jù)，那么此時(shí)每一個(gè)數(shù)據(jù)庫都將生成一個(gè)屬于自己的回滾日志文件，用于分別記錄屬于自己的數(shù)據(jù)改變，與此同時(shí)還要生成一個(gè)用于協(xié)調(diào)多個(gè)數(shù)據(jù)庫操作的主數(shù)據(jù)庫日志文件，在主數(shù)據(jù)庫日志文件中將包含各個(gè)數(shù)據(jù)庫回滾日志文件的文件名，在每個(gè)回滾日志文件中也同樣包含了主數(shù)據(jù)庫日志文件的文件名信息。然而對(duì)于無需主數(shù)據(jù)庫日志文件的回滾日志文件，其中也會(huì)保留主數(shù)據(jù)庫日志文件的信息，只是此時(shí)該信息的值為空。
    我們可以將回滾日志視為"HOT"日志文件，因?yàn)樗拇嬖诰褪菫榱嘶謴?fù)數(shù)據(jù)庫的一致性狀態(tài)。當(dāng)某一進(jìn)程正在更新數(shù)據(jù)庫時(shí)，應(yīng)用程序或OS突然崩潰，這樣更新操作就不能順利完成。因此我們可以說"HOT"日志只有在異常條件下才會(huì)生成，如果一切都非常順利的話，該文件將永遠(yuǎn)不會(huì)存在。

四、數(shù)據(jù)寫入：

    如果某一進(jìn)程要想在數(shù)據(jù)庫上執(zhí)行寫操作，那么必須先獲取共享鎖，在共享鎖獲取之后再獲取保留鎖。因?yàn)楸Ａ翩i則預(yù)示著在將來某一時(shí)刻該進(jìn)程將會(huì)執(zhí)行寫操作，所以在同一時(shí)刻只有一個(gè)進(jìn)程可以持有一把保留鎖，但是其它進(jìn)程可以繼續(xù)持有共享鎖以完成數(shù)據(jù)讀取的操作。如果要執(zhí)行寫操作的進(jìn)程不能獲取保留鎖，那么這將說明另一進(jìn)程已經(jīng)獲取了保留鎖。在此種情況下，寫操作將失敗，并立即返回SQLITE_BUSY錯(cuò)誤。在成功獲取保留鎖之后，該寫進(jìn)程將創(chuàng)建回滾日志。
    在對(duì)任何數(shù)據(jù)作出改變之前，寫進(jìn)程會(huì)將待修改頁中的原有內(nèi)容先行寫入回滾日志文件中，然而，這些數(shù)據(jù)發(fā)生變化的頁起初并不會(huì)直接寫入磁盤文件，而是保留在內(nèi)存中，這樣其它進(jìn)程就可以繼續(xù)讀取該數(shù)據(jù)庫中的數(shù)據(jù)了。
    或者是因?yàn)閮?nèi)存中的cache已滿，或者是應(yīng)用程序已經(jīng)提交了事務(wù)，最終，寫進(jìn)程將數(shù)據(jù)更新到數(shù)據(jù)庫文件中。然而在此之前，寫進(jìn)程必須確保沒有其它的進(jìn)程正在讀取數(shù)據(jù)庫，同時(shí)回滾日志中的數(shù)據(jù)確實(shí)被物理的寫入到磁盤文件中，其步驟如下：
    1). 確保所有的回滾日志數(shù)據(jù)被物理的寫入磁盤文件，以便在出現(xiàn)系統(tǒng)崩潰時(shí)可以將數(shù)據(jù)庫恢復(fù)到一致的狀態(tài)。
    2). 獲取PENDING鎖，再獲取排他鎖，如果此時(shí)其它的進(jìn)程仍然持有共享鎖，寫入線程將不得不被掛起并等待直到那些共享鎖消失之后，才能進(jìn)而得到排他鎖。
    3). 將內(nèi)存中持有的修改頁寫出到原有的磁盤文件中。
    如果寫入到數(shù)據(jù)庫文件的原因是因?yàn)閏ache已滿，那么寫入進(jìn)程將不會(huì)立刻提交，而是繼續(xù)對(duì)其它頁進(jìn)行修改。但是在接下來的修改被寫入到數(shù)據(jù)庫文件之前，回滾日志必須被再一次寫到磁盤中。還要注意的是，寫入進(jìn)程獲取到的排他鎖必須被一直持有，直到所有的改變被提交時(shí)為止。這也意味著，從數(shù)據(jù)第一次被刷新到磁盤文件開始，直到事務(wù)被提交之前，其它的進(jìn)程不能訪問該數(shù)據(jù)庫。
    當(dāng)寫入進(jìn)程準(zhǔn)備提交時(shí)，將遵循以下步驟：
    4). 獲取排他鎖，同時(shí)確保所有內(nèi)存中的變化數(shù)據(jù)都被寫入到磁盤文件中。
    5). 將所有數(shù)據(jù)庫文件的變化數(shù)據(jù)物理的寫入到磁盤中。
    6). 刪除日志文件。如果在刪除之前出現(xiàn)系統(tǒng)故障，進(jìn)程在下一次打開該數(shù)據(jù)庫時(shí)仍將基于該HOT日志進(jìn)行恢復(fù)操作。因此只有在成功刪除日志文件之后，我們才可以認(rèn)為該事務(wù)成功完成。
    7). 從數(shù)據(jù)庫文件中刪除所有的排他鎖和PENDING鎖。
    一旦PENDING鎖被釋放，其它的進(jìn)程就可以開始再次讀取數(shù)據(jù)庫了。
    如果一個(gè)事務(wù)中包含多個(gè)數(shù)據(jù)庫的修改，那么它的提交邏輯將更為復(fù)雜，見如下步驟：
    4). 確保每個(gè)數(shù)據(jù)庫文件都已經(jīng)持有了排他鎖和一個(gè)有效的日志文件。
    5). 創(chuàng)建主數(shù)據(jù)庫日志文件，同時(shí)將每個(gè)數(shù)據(jù)庫的回滾日志文件的文件名寫入到該主數(shù)據(jù)庫日志文件中。
    6). 再將主數(shù)據(jù)庫日志文件的文件名分別寫入到每個(gè)數(shù)據(jù)庫回滾日志文件的指定位置中。
    7). 將所有的數(shù)據(jù)庫變化持久化到數(shù)據(jù)庫磁盤文件中。
    8). 刪除主日志文件，如果在刪除之前出現(xiàn)系統(tǒng)故障，進(jìn)程在下一次打開該數(shù)據(jù)庫時(shí)仍將基于該HOT日志進(jìn)行恢復(fù)操作。因此只有在成功刪除主日志文件之后，我們才可以認(rèn)為該事務(wù)成功完成。
    9). 刪除每個(gè)數(shù)據(jù)庫各自的日志文件。
    10).從所有數(shù)據(jù)庫中刪除掉排他鎖和PENDING鎖。
   
    最后需要說明的是，在SQLite2中，如果多個(gè)進(jìn)程正在從數(shù)據(jù)庫中讀取數(shù)據(jù)，也就是說該數(shù)據(jù)庫始終都有讀操作發(fā)生，即在每一時(shí)刻該數(shù)據(jù)庫都持有至少一把共享鎖，這樣將會(huì)導(dǎo)致沒有任何進(jìn)程可以執(zhí)行寫操作，因?yàn)樵跀?shù)據(jù)庫持有讀鎖的時(shí)候是無法獲取寫鎖的，我們將這種情形稱為"寫?zhàn)囸I"。在SQLite3中，通過使用PENDING鎖則有效的避免了"寫?zhàn)囸I"情形的發(fā)生。當(dāng)某一進(jìn)程持有PENDING鎖時(shí)，已經(jīng)存在的讀操作可以繼續(xù)進(jìn)行，直到其正常結(jié)束，但是新的讀操作將不會(huì)再被SQLite接受，所以在已有的讀操作全部結(jié)束后，持有PENDING鎖的進(jìn)程就可以被激活并試圖進(jìn)一步獲取排他鎖以完成數(shù)據(jù)的修改操作。
   
五、SQL級(jí)別的事務(wù)控制：

    SQLite3在實(shí)現(xiàn)上確實(shí)針對(duì)鎖和并發(fā)控制做出了一些精巧的變化，特別是對(duì)于事務(wù)這一SQL語言級(jí)別的特征。在缺省情況下，SQLite3會(huì)將所有的SQL操作置于antocommit模式下，這樣所有針對(duì)數(shù)據(jù)庫的修改操作都會(huì)在SQL命令執(zhí)行結(jié)束后被自動(dòng)提交。在SQLite中，SQL命令"BEGIN TRANSACTION"用于顯式的聲明一個(gè)事務(wù)，即其后的SQL語句在執(zhí)行后都不會(huì)自動(dòng)提交，而是需要等到SQL命令"COMMIT"或"ROLLBACK"被執(zhí)行時(shí)，才考慮提交還是回滾。由此可以推斷出，在BEGIN命令被執(zhí)行后并沒有立即獲得任何類型的鎖，而是在執(zhí)行第一個(gè)SELECT語句時(shí)才得到一個(gè)共享鎖，或者是在執(zhí)行第一個(gè)DML語句時(shí)才獲得一個(gè)保留鎖。至于排它鎖，只有在數(shù)據(jù)從內(nèi)存寫入磁盤時(shí)開始，直到事務(wù)提交或回滾之前才能持有排它鎖。
    如果多個(gè)SQL命令在同一個(gè)時(shí)刻同一個(gè)數(shù)據(jù)庫連接中被執(zhí)行，autocommit將會(huì)被延遲執(zhí)行，直到最后一個(gè)命令完成。比如，如果一個(gè)SELECT語句正在被執(zhí)行，在這個(gè)命令執(zhí)行期間，需要返回所有檢索出來的行記錄，如果此時(shí)處理結(jié)果集的線程因?yàn)闃I(yè)務(wù)邏輯的需要被暫時(shí)掛起并處于等待狀態(tài)，而其它的線程此時(shí)或許正在該連接上對(duì)該數(shù)據(jù)庫執(zhí)行INSERT、UPDATE或DELETE命令，那么所有這些命令作出的數(shù)據(jù)修改都必須等到SELECT檢索結(jié)束后才能被提交。

    這是該系列中最后一篇關(guān)于SQLite理論與應(yīng)用方面的博客了，后面將發(fā)布兩篇關(guān)于如何利用SQLite編程的博客，其中還將包含四個(gè)典型的應(yīng)用代碼示例，望大家繼續(xù)保持關(guān)注。