sqlite的事務和鎖

l_serein發表於2012-10-30
SQLite
事務 
事務定義了一組SQL命令的邊界，這組命令或者作為一個整體被全部執行，或者都不執行。事務的典型例項是轉帳。
事務的範圍 
事務由3個命令控制：BEGIN、COMMIT和ROLLBACK。BEGIN開始一個事務，之後的所有操作都可以取消。COMMIT使BEGIN後的所有命令得到確認；而ROLLBACK還原BEGIN之後的所有操作。如： 
sqlite> BEGIN; 
sqlite> DELETE FROM foods; 
sqlite> ROLLBACK; 
sqlite> SELECT COUNT(*) FROM foods; 
COUNT(*) 
412 
上面開始了一個事務，先刪除了foods表的所有行，但是又用ROLLBACK進行了回捲。再執行SELECT時發現表中沒發生任何改變。 
SQLite預設情況下，每條SQL語句自成事務(自動提交模式)。 
衝突解決 
如前所述，違反約束會導致事務的非法結束。大多數資料庫(管理系統)都是簡單地將前面所做的修改全部取消。 
SQLite有其獨特的方法來處理約束違反(或說從約束違反中恢復)，被稱為衝突解決。 
如： 
sqlite> UPDATE foods SET id=800-id; 
SQL error: PRIMARY KEY must be unique 
SQLite提供5種衝突解決方案：REPLACE、IGNORE、FAIL、ABORT和ROLLBACK。 
REPLACE: 當發違反了唯一完整性，SQLite將造成這種違反的記錄刪除，替代以新插入或修改的新記錄，SQL繼續執行，不報錯。 
IGNORE 
FAIL 
ABORT 
ROLLBACK 
資料庫鎖 
在SQLite中，鎖和事務是緊密聯絡的。為了有效地使用事務，需要了解一些關於如何加鎖的知識。 
SQLite採用粗放型的鎖。當一個連線要寫資料庫，所有其它的連線被鎖住，直到寫連線結束了它的事務。SQLite有一個加鎖表，來幫助不同的寫資料庫都能夠在最後一刻再加鎖，以保證最大的併發性。 
SQLite使用鎖逐步上升機制，為了寫資料庫，連線需要逐級地獲得排它鎖。SQLite有5個不同的鎖狀態：未加鎖(UNLOCKED)、共享(SHARED)、保留(RESERVED)、未決(PENDING)和排它(EXCLUSIVE)。每個資料庫連線在同一時刻只能處於其中一個狀態。每種狀態(未加鎖狀態除外)都有一種鎖與之對應。 
最初的狀態是未加鎖狀態，在此狀態下，連線還沒有存取資料庫。當連線到了一個資料庫，甚至已經用BEGIN開始了一個事務時，連線都還處於未加鎖狀態。 
未加鎖狀態的下一個狀態是共享狀態。為了能夠從資料庫中讀(不寫)資料，連線必須首先進入共享狀態，也就是說首先要獲得一個共享鎖。多個連線可以同時獲得並保持共享鎖，也就是說多個連線可以同時從同一個資料庫中讀資料。但哪怕只有一個共享鎖還沒有釋放，也不允許任何連線寫資料庫。 
如果一個連線想要寫資料庫，它必須首先獲得一個保留鎖。一個資料庫上同時只能有一個保留鎖。保留鎖可以與共享鎖共存，保留鎖是寫資料庫的第1階段。保留鎖即不阻止其它擁有共享鎖的連線繼續讀資料庫，也不阻止其它連線獲得新的共享鎖。 
一旦一個連線獲得了保留鎖，它就可以開始處理資料庫修改操作了，儘管這些修改只能在緩衝區中進行，而不是實際地寫到磁碟。對讀出內容所做的修改儲存在記憶體緩衝區中。 
當連線想要提交修改(或事務)時，需要將保留鎖提升為排它鎖。為了得到排它鎖，還必須首先將保留鎖提升為未決鎖。獲得未決鎖之後，其它連線就不能再獲得新的共享鎖了，但已經擁有共享鎖的連線仍然可以繼續正常讀資料庫。此時，擁有未決鎖的連線等待其它擁有共享鎖的連線完成工作並釋放其共享鎖。 
一旦所有其它共享鎖都被釋放，擁有未決鎖的連線就可以將其鎖提升至排它鎖，此時就可以自由地對資料庫進行修改了。所有以前對緩衝區所做的修改都會被寫到資料庫檔案。 
死鎖 
為什麼需要了解鎖的機制呢？為了避免死鎖。 
考慮下面表4-7所假設的情況。兩個連線——A和B——同時但完全獨立地工作於同一個資料庫。A執行第1條命令，B執行第2、3條，等等。 
表4-7 一個死鎖的假設情況 

A連線                                     B連線 
sqlite> BEGIN; 
                                    sqlite> BEGIN; 
                                    sqlite> INSERT INTO foo VALUES('x'); 
sqlite> SELECT * FROM foo; 
                                    sqlite> COMMIT; 
                                    SQL error: database is locked 
sqlite> INSERT INTO foo VALUES ('x'); 
SQL error: database is locked 

兩個連線都在死鎖中結束。B首先嚐試寫資料庫，也就擁有了一個未決鎖。A再試圖寫，但當其INSERT語句試圖將共享鎖提升為保留鎖時失敗。 
為了討論的方便，假設連線A和B都一直等待資料庫可寫。那麼此時，其它的連線甚至都不能夠再讀資料庫了，因為B擁有未決鎖(它能阻止其它連線獲得共享鎖)。那麼時此，不僅A和B不能工作，其它所有程式都不能再操作此資料庫了。 
如果避免此情況呢？當然不能讓A和B通過談判解決，因為它們甚至不知道彼此的存在。答案是採用正確的事務型別來完成工作。 
事務的種類 
SQLite有三種不同的事務，使用不同的鎖狀態。事務可以開始於：DEFERRED、MMEDIATE或EXCLUSIVE。事務型別在BEGIN命令中指定： 
BEGIN [ DEFERRED | IMMEDIATE | EXCLUSIVE ] TRANSACTION; 
一個DEFERRED事務不獲取任何鎖(直到它需要鎖的時候)，BEGIN語句本身也不會做什麼事情——它開始於UNLOCK狀態。預設情況下就是這樣的，如果僅僅用BEGIN開始一個事務，那麼事務就是DEFERRED的，同時它不會獲取任何鎖；當對資料庫進行第一次讀操作時，它會獲取SHARED鎖；同樣，當進行第一次寫操作時，它會獲取RESERVED鎖。 
由BEGIN開始的IMMEDIATE事務會嘗試獲取RESERVED鎖。如果成功，BEGIN IMMEDIATE保證沒有別的連線可以寫資料庫。但是，別的連線可以對資料庫進行讀操作；但是，RESERVED鎖會阻止其它連線的BEGIN IMMEDIATE或者BEGIN EXCLUSIVE命令，當其它連線執行上述命令時，會返回SQLITE_BUSY錯誤。這時你就可以對資料庫進行修改操作了，但是你還不能提交，當你COMMIT時，會返回SQLITE_BUSY錯誤，這意味著還有其它的讀事務沒有完成，得等它們執行完後才能提交事務。 
EXCLUSIVE事務會試著獲取對資料庫的EXCLUSIVE鎖。這與IMMEDIATE類似，但是一旦成功，EXCLUSIVE事務保證沒有其它的連線，所以就可對資料庫進行讀寫操作了。 
上節那個例子的問題在於兩個連線最終都想寫資料庫，但是它們都沒有放棄各自原來的鎖，最終，SHARED鎖導致了問題的出現。如果兩個連線都以BEGIN IMMEDIATE開始事務，那麼死鎖就不會發生。在這種情況下，在同一時刻只能有一個連線進入BEGIN IMMEDIATE，其它的連線就得等待。BEGIN IMMEDIATE和BEGIN EXCLUSIVE通常被寫事務使用。就像同步機制一樣，它防止了死鎖的產生。 
基本的準則是：如果你正在使用的資料庫沒有其它的連線，用BEGIN就足夠了。但是，如果你使用的資料庫有其它的連線也會對資料庫進行寫操作，就得使用BEGIN IMMEDIATE或BEGIN EXCLUSIVE開始你的事務。 

相關文章