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

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

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

幻影讀 ：待續...

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

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

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

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

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

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

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

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

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

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

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


JDBC事務級別

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

TRANSACTION_NONE 說明不支持事務。


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


TRANSACTION_READ_COMMITTED 說明讀取未提交的數據是不允許的。這個級別仍然允許不可重復的讀和虛讀產生。


TRANSACTION_REPEATABLE_READ 說明事務保證能夠再次讀取相同的數據而不會失敗，但虛讀仍然會出現。


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

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

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


轉：www.csdn.net