事務
事務定義了一組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開始你的事務。
事務和鎖 SQLite
2 事務 transaction 2.1 事務的週期 transaction lifecycles 程 序與事務之間有兩件事值得注意 1 哪些物件在事務下執行 這直接與api有關。2 事務的生命週期，即什麼時候開始，什麼時候結束以及它在什麼時候開始影響別的連線 這點對於併發性很重要 這涉及到sqli...
事務和鎖 SQLite
2 事務 transaction 2.1 事務的週期 transaction lifecycles 程 序與事務之間有兩件事值得注意 1 哪些物件在事務下執行 這直接與api有關。2 事務的生命週期，即什麼時候開始，什麼時候結束以及它在什麼時候開始影響別的連線 這點對於併發性很重要 這涉及到sqli...
事務和鎖 SQLite
2 事務 transaction 2.1 事務的週期 transaction lifecycles 程 序與事務之間有兩件事值得注意 1 哪些物件在事務下執行 這直接與api有關。2 事務的生命週期，即什麼時候開始，什麼時候結束以及它在什麼時候開始影響別的連線 這點對於併發性很重要 這涉及到sqli...