轉自：
http://blog.csdn.net/tianzhihen_wq/article/details/45191473
SQL事務：
http://www.runoob.com/sqlite/sqlite-transaction.html
事務
事務定義了一組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 uniqueSQLite提供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開始你的事務。
sqlite3使用事務處理[zz]
在對 sqlite3 insert into 等操作時速度比較慢。
原因：它以文件的形式存在磁盤中，每次訪問時都要打開一次文件，如果對數據庫進行大量的操作，就很慢。
解決辦法：用事物的形式提交，因爲開始事務後，進行的大量操作語句都保存在內存中，當提交時才全部寫入數據庫，此時，數據庫文件也只用打開一次。如果操作錯誤，還可以回滾事務。
接口：事務的操作沒有特別的接口函數，就是一個普通的 sql 語句而已，分別如下：
int ret ;
ret = sqlite3_exec ( db , “begin transaction” , 0 , 0 , & zErrorMsg ); // 開始一個事務
ret = sqlite3_exec ( db , “commit transaction” , 0 , 0 , & zErrorMsg ); // 提交事務
ret = sqlite3_exec ( db , “rollback transaction” , 0 , 0 , & zErrorMsg );例程：在進行大量的操作前使用如下語句
ret = sqlite3_exec ( db , “begin transaction” , 0 , 0 ,& zErrorMsg );
for (…)
{//insert into operate
// 如果操作錯誤
ret = sqlite3_exec ( db , “rollback transaction” , 0 , 0 , & zErrorMsg )
}
ret = sqlite3_exec ( db , “commit transaction” , 0 , 0 , & zErrorMsg );開發過程遇到這樣的問題：
分別對兩個數據庫文件的不同表進行操作，執行順序爲： open db A->begin trasaction->open db B->select from db B->close db B->select from db A->rollbak or commit->close db A
測試發現， select from db B 這一步會出錯，錯誤信息爲library routine called out of sequence ，出錯後執行 rollback ，這一步也會報錯。
原來以爲原因是：開始一個事務只能對一個數據庫進行操作。
測試發現，即使不開始事務，執行順序爲： open db A->open db B->select from db B->close db B->select from db A->close db A ， 仍會出現ibrary routine called out of sequence 的錯誤。