下面內(nèi)容是從網(wǎng)上找到的博文，先貼下，接下來的時間會慢慢結合自己的實例來一一驗證并總結下面概念的論述。

在介紹JDBC事務的應用之前，先了解一下數(shù)據(jù)庫事務中的事務操作的幾個概念。
臟讀 dirty reads：
當事務讀取還未被提交的數(shù)據(jù)時，就會發(fā)生這種事件。舉例來說：Transaction 1 修改了一行數(shù)據(jù)，然后 Transaction 2 在 Transaction 1 還未提交修改操作之前讀取了被修改的行。如果 Transaction 1 回滾了修改操作，那么 Transaction 2 讀取的數(shù)據(jù)就可以看作是從未存在過的。
   
不可重復的讀 non-repeatable reads：
當事務兩次讀取同一行數(shù)據(jù)，但每次得到的數(shù)據(jù)都不一樣時，就會發(fā)生這種事件。舉例來說：Transaction 1 讀取一行數(shù)據(jù)，然后 Transaction 2 修改或刪除該行并提交修改操作。當 Transaction 1 試圖重新讀取該行時，它就會得到不同的數(shù)據(jù)值（如果該行被更新）或發(fā)現(xiàn)該行不再存在（如果該行被刪除）。    

虛讀 phantom read：
如果符合搜索條件的一行數(shù)據(jù)在后面的讀取操作中出現(xiàn)，但該行數(shù)據(jù)卻不屬于最初的數(shù)據(jù)，就會發(fā)生這種事件。舉例來說：Transaction 1 讀取滿足某種搜索條件的一些行，然后Transaction 2 插入了符合 Transaction 1 的搜索條件的一個新行。如果 Transaction 1 重新執(zhí)行產(chǎn)生原來那些行的查詢，就會得到不同的行。

幻影讀 ：待續(xù)...

事務場景是這樣的：
對于同一個銀行帳戶A內(nèi)有200元，甲進行提款操作100元，乙進行轉帳操作100元到B帳戶。如果事務沒有進行隔離可能會并發(fā)如下問題：

1、第一類丟失更新：首先甲提款時帳戶內(nèi)有200元，同時乙轉帳也是200元，然后甲乙同時操作，甲操作成功取走100元，乙操作失敗回滾，帳戶內(nèi)最終為200元，這樣甲的操作被覆蓋掉了，銀行損失100元。

2、臟讀：甲取款100元未提交，乙進行轉帳查到帳戶內(nèi)剩有100元，這是甲放棄操作回滾，乙正常操作提交，帳戶內(nèi)最終為0元，乙讀取了甲的臟數(shù)據(jù)，客戶損失100元。

3、虛讀：和臟讀類似，是針對于插入操作過程中的讀取問題，如丙存款100元未提交，這時銀行做報表進行統(tǒng)計查詢帳戶為200元，然后丙提交了，這時銀行再統(tǒng)計發(fā)現(xiàn)帳戶為300元了，無法判斷到底以哪個為準？
大家好像覺得統(tǒng)計這個東西肯定是時時更新的，這種情況很正常；但是如果統(tǒng)計是在一個事務中的時候就不正常了，比如我們的一個統(tǒng)計應用需要將統(tǒng)計結果分別輸出到電腦屏幕和遠程網(wǎng)絡某臺計算機的磁盤文件中，為了提高性能和用戶響應我們分成2個線程，這時先完成的和后完成的統(tǒng)計數(shù)據(jù)就可能不一致，我們就不知道以哪個為準了。

4、不可重復讀：甲乙同時開始都查到帳戶內(nèi)為200元，甲先開始取款100元提交，這時乙在準備最后更新的時候又進行了一次查詢，發(fā)現(xiàn)結果是100元，這時乙就會很困惑，不知道該將帳戶改為100還是0。
和臟讀的區(qū)別是，臟讀是讀取前一事務未提交的臟數(shù)據(jù)，不可重復讀是重新讀取了前一事務已提交的數(shù)據(jù)。

5、第二類丟失更新：是不可重復讀的一種特例，如上，乙不做第二次查詢而是直接操作完成，帳戶內(nèi)最終為100元，甲的操作被覆蓋掉了，銀行損失100元。感覺和第一類丟失更新類似。

在多個事務并發(fā)做數(shù)據(jù)庫操作的時候，如果沒有有效的避免機制，就會出現(xiàn)種種問題。大體上有三種問題，歸結如下：

1、丟失更新
如果兩個事務都要更新數(shù)據(jù)庫一個字段X，x=100
事務A             事務B
讀取X＝100    
                  讀取X＝100
寫入x＝X+100
                  寫入x＝X+200
事務結束x=200
                  事務結束x=300
最后x==300
這種情況事務A的更新就被覆蓋掉了、丟失了。
丟失更新說明事務進行數(shù)據(jù)庫寫操作的時候可能會出現(xiàn)的問題。

2、不可重復讀
一個事務在自己沒有更新數(shù)據(jù)庫數(shù)據(jù)的情況，同一個查詢操作執(zhí)行兩次或多次的結果應該是一致的；如果不一致，就說明為不可重復讀。
還是用上面的例子
事務A             事務B
讀取X＝100    
                  讀取X＝100
讀取X＝100    
                  寫入x＝X+100
讀取X＝200    
事務結束x=200
                  事務結束x=200
這種情況事務A多次讀取x的結果出現(xiàn)了不一致，即為不可重復讀。
再有一情況就是幻影
事務A讀的時候讀出了15條記錄，事務B在事務A執(zhí)行的過程中刪除（增加）了1條，事務A再讀的時候就變成了14（16）條，這種情況就叫做幻影讀。
不可重復讀說明了做數(shù)據(jù)庫讀操作的時候可能會出現(xiàn)的問題。

3、臟讀（未提交讀）
防止一個事務讀到另一個事務還沒有提交的記錄。
如：
事務A             事務B
                  讀取X＝100
                  寫入x＝X+100
讀取X＝200    
                  事務回滾x=100
讀取X＝100    
事務結束x=100

x鎖 排他鎖 被加鎖的對象只能被持有鎖的事務讀取和修改，其他事務無法在該對象上加其他鎖，也不能讀取和修改該對象
s鎖 共享鎖 被加鎖的對象可以被持鎖事務讀取，但是不能被修改，其他事務也可以在上面再加s鎖。
封鎖協(xié)議：
一級封鎖協(xié)議：
在事務修改數(shù)據(jù)的時候加x鎖，直到事務結束（提交或者回滾）釋放x鎖。一級封鎖協(xié)議可以有效的防止丟失更新，但是不能防止臟讀不可重復讀的出現(xiàn)。
二級封鎖協(xié)議：
在一級封鎖的基礎上事務讀數(shù)據(jù)的時候加s鎖，讀取之后釋放。二級封鎖協(xié)議可以防止丟失更新，臟讀。不能防止不可重復讀。
三級封鎖協(xié)議：
在一級封鎖的基礎上事務讀數(shù)據(jù)的時候加s鎖，直到事務結束釋放。二級封鎖協(xié)議可以防止丟失更新，臟讀，不可重復讀。


JDBC事務級別

為了解決與“多個線程請求相同數(shù)據(jù)”相關的問題，事務之間用鎖相互隔開。多數(shù)主流的數(shù)據(jù)庫支持不同類型的鎖；因此，JDBC API 支持不同類型的事務，它們由 Connection 對象指派或確定。在 JDBC API 中可以獲得下列事務級別：

TRANSACTION_NONE 說明不支持事務。


TRANSACTION_READ_UNCOMMITTED 說明在提交前一個事務可以看到另一個事務的變化。這樣臟讀、不可重復的讀和虛讀都是允許的。


TRANSACTION_READ_COMMITTED 說明讀取未提交的數(shù)據(jù)是不允許的。這個級別仍然允許不可重復的讀和虛讀產(chǎn)生。


TRANSACTION_REPEATABLE_READ 說明事務保證能夠再次讀取相同的數(shù)據(jù)而不會失敗，但虛讀仍然會出現(xiàn)。


TRANSACTION_SERIALIZABLE 是最高的事務級別，它防止臟讀、不可重復的讀和虛讀。
您可能想知道，為什么不是所有事務都運行在 TRANSACTION_SERIALIZABLE 模式以保證最高程度的數(shù)據(jù)完整性呢？問題在于，和處理多線程編程有關的問題相似，事務保護的級別越高，性能損失就越大。

假定您的數(shù)據(jù)庫和 JDBC 驅(qū)動程序支持這個特性，則給定一個 Connection 對象，您可以明確地設置想要的事務級別：
con.setTransactionLevel(TRANSACTION_SERIALIZABLE) ;
您還可以確定當前事務的級別：

if(con.getTransactionLevel() == TRANSACTION_SERIALIZABLE)
  System.out.println("Highest Transaction Level in operation.") ;


轉：www.csdn.net