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

在介紹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元，乙進行轉(zhuǎn)帳操作100元到B帳戶。如果事務沒有進行隔離可能會并發(fā)如下問題：

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

2、臟讀：甲取款100元未提交，乙進行轉(zhuǎn)帳查到帳戶內(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)計結(jié)果分別輸出到電腦屏幕和遠程網(wǎng)絡某臺計算機的磁盤文件中，為了提高性能和用戶響應我們分成2個線程，這時先完成的和后完成的統(tǒng)計數(shù)據(jù)就可能不一致，我們就不知道以哪個為準了。

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

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

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

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

2、不可重復讀
一個事務在自己沒有更新數(shù)據(jù)庫數(shù)據(jù)的情況，同一個查詢操作執(zhí)行兩次或多次的結(jié)果應該是一致的；如果不一致，就說明為不可重復讀。
還是用上面的例子
事務A             事務B
讀取X＝100    
                  讀取X＝100
讀取X＝100    
                  寫入x＝X+100
讀取X＝200    
事務結(jié)束x=200
                  事務結(jié)束x=200
這種情況事務A多次讀取x的結(jié)果出現(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    
事務結(jié)束x=100

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


轉(zhuǎn)：www.csdn.net