概述
    不管你直接採用JDBC進行資料庫事務操作，還是使用基於Spring或EJB的宣告式事務功能進行事務管理，它們最終都是使用底層資料庫的事務管理功能 完成最終任務的。資料庫事務擁有許多語義概念，它們是你進行事務程式設計和事務管理的基礎，只有掌握好資料庫事務的基礎知識，才能深刻理解資料庫事務，進而開 發出正確合理的應用。

    文將對應用開發中所涉及的資料庫事務知識進行概括性的講解，相信這些知識會給你的資料庫應用開發帶來幫助。

何為資料庫事務
    “一榮俱榮，一損俱損”這句話很能體現事務的思想，很多複雜的事物要分步進行，但它們組成一個整體，要麼整體生效，要麼整體失效。這種思想反映到資料庫上，就是多個SQL語句，要麼所有執行成功，要麼所有執行失敗。
資料庫事務有嚴格的定義，它必須同時滿足四個特性：原子性（Atomic）、一致性（Consistency）、隔離性（Isolation）和永續性（Durabiliy），簡稱為ACID。下面是對每個特性的說明：
 原子性：表示組成一個事務的多個數據庫操作是一個不可分隔的原子單元，只有所有的操作執行成功，整個事務才提交，事務中任何一個數據庫操作失敗，已經執行的任何操作都必須撤銷，讓資料庫返回到初始狀態；
 一致性：事務操作成功後，資料庫所處的狀態和它的業務規則是一致的，即資料不會被破壞。如從A賬戶轉賬100元到B賬戶，不管操作成功與否，A和B的存款總額是不變的；
 隔離性：在併發資料操作時，不同的事務擁有各自資料空間，它們的操作不會對對方產生干擾。準確的說，並非要求做到完全無干擾，資料庫規定了多種事務隔離級別，不同隔離級別對應不同的干擾程度，隔離級別越高，資料一致性越好，但併發性越弱；
 永續性：一旦事務提交成功後，事務中所有的資料操作都必須被持久化到資料庫中，即使提交事務後，資料庫馬上崩潰，在資料庫重啟時，也必須能保證能夠通過某種機制恢復資料。

    在這些事務特性中，資料“一致性”是最終目標，其它的特性都是為達到這個目標的措施、要求或手段。
數 據庫管理系統一般採用重執行日誌保證原子性、一致性和永續性，重執行日誌記錄了資料庫變化的每一個動作，資料庫在一個事務中執行一部分操作後發生錯誤退 出，資料庫即可以根據重執行日誌撤銷已經執行的操作。此外，對於已經提交的事務，即使資料庫崩潰，在重啟資料庫時也能夠根據日誌對尚未持久化的資料進行相 應的重執行操作。

    和Java程式採用物件鎖機制進行執行緒同步類似，資料庫管理系統採用資料庫鎖機制保證事務的隔離性。當多個事務試圖對相同的資料進行操作時，只有持有鎖的 事務才能操作資料，直到前一個事務完成後，後面的事務才有機會對資料進行操作。Oracle資料庫還使用了資料版本的機制，在回滾段為資料的每個變化都保 存一個版本，使資料的更改不影響資料的讀取。

資料併發的問題
    一個數據庫可能擁有多個訪問客戶端，這些客戶端都可以併發方式訪問資料庫。資料庫中的相同資料可能同時被多個事務訪問，如果沒有采取必要的隔離措施，就會 導致各種併發問題，破壞資料的完整性。這些問題可以歸結為5類，包括3類資料讀問題（髒讀、幻象讀和不可重複讀）以及2類資料更新問題（第一類丟失更新和 第二類丟失更新）。下面，我們分別通過例項講解引發問題的場景。

髒讀（dirty read）
    在講解髒讀前，我們先講一個笑話：一個有結巴的人在飲料店櫃檯前轉悠，老闆很熱情地迎上來：“喝一瓶？”，結巴連忙說：“我…喝…喝…”，老闆麻利地開啟 易拉罐遞給結巴，結巴終於憋出了他的那句話：“我…喝…喝…喝不起啊！”。在這個笑話中，飲料店老闆就對結巴進行了髒讀。
A事務讀取B事務尚未提交的更改資料，並在這個資料的基礎上操作。如果恰巧B事務回滾，那麼A事務讀到的資料根本是不被承認的。來看取款事務和轉賬事務併發時引發的髒讀場景：
     

時間	轉賬事務A	取款事務B
T1	開始事務
T2	開始事務
T3	查詢賬戶餘額為1000元
T4	取出500元把餘額改為500元
T5	查詢賬戶餘額為500元（髒讀）
T6	撤銷事務餘額恢復為1000元
T7	匯入100元把餘額改為600元
T8	提交事務

 
    在這個場景中，B希望取款500元而後又撤銷了動作，而A往相同的賬戶中轉賬100元，就因為A事務讀取了B事務尚未提交的資料，因而造成賬戶白白丟失了500元。在Oracle資料庫中，不會發生髒讀的情況。

不可重複讀（unrepeatable read）
   不可重複讀是指A事務讀取了B事務已經提交的更改資料。假設A在取款事務的過程中，B往該賬戶轉賬100元，A兩次讀取賬戶的餘額發生不一致：

時間	取款事務A	轉賬事務B
T1	開始事務
T2	開始事務
T3	查詢賬戶餘額為1000元
T4	查詢賬戶餘額為1000元
T5	取出100元把餘額改為900元
T6	提交事務
T7	查詢賬戶餘額為900元（和T4讀取的不一致）

 
  在同一事務中，T4時間點和T7時間點讀取賬戶存款餘額不一樣。

幻象讀（phantom read）
    A事務讀取B事務提交的新增資料，這時A事務將出現幻象讀的問題。幻象讀一般發生在計算統計資料的事務中，舉一個例子，假設銀行系統在同一個事務中，兩 次統計存款賬戶的總金額，在兩次統計過程中，剛好新增了一個存款賬戶，並存入100元，這時，兩次統計的總金額將不一致：  

時間	統計金額事務A	轉賬事務B
T1	開始事務
T2	開始事務
T3	統計總存款數為10000元
T4	新增一個存款賬戶，存款為100元
T5	提交事務
T6	再次統計總存款數為10100元（幻象讀）

    如果新增資料剛好滿足事務的查詢條件，這個新資料就進入了事務的視野，因而產生了兩個統計不一致的情況。
幻象讀和不可重複讀是 兩個容易混淆的概念，前者是指讀到了其它已經提交事務的新增資料，而後者是指讀到了已經提交事務的更改資料（更改或刪除），為了避免這兩種情況，採取的對 策是不同的，防止讀取到更改資料，只需要對操作的資料新增行級鎖，阻止操作中的資料發生變化，而防止讀取到新增資料，則往往需要新增表級鎖——將整個表鎖 定，防止新增資料（Oracle使用多版本資料的方式實現）。

第一類丟失更新
    A事務撤銷時，把已經提交的B事務的更新資料覆蓋了。這種錯誤可能造成很嚴重的問題，通過下面的賬戶取款轉賬就可以看出來： 
    

時間	取款事務A	轉賬事務B
T1	開始事務
T2	開始事務
T3	查詢賬戶餘額為1000元
T4	查詢賬戶餘額為1000元
T5	匯入100元把餘額改為1100元
T6	提交事務
T7	取出100元把餘額改為900元
T8	撤銷事務
T9	餘額恢復為1000元（丟失更新）

A事務在撤銷時，“不小心”將B事務已經轉入賬戶的金額給抹去了。
    第二類丟失更新
A事務覆蓋B事務已經提交的資料，造成B事務所做操作丟失：  

時間	轉賬事務A	取款事務B
T1	開始事務
T2	開始事務
T3	查詢賬戶餘額為1000元
T4	查詢賬戶餘額為1000元
T5	取出100元把餘額改為900元
T6	提交事務
T7	匯入100元
T8	提交事務
T9	把餘額改為1100元（丟失更新）

    上面的例子裡由於支票轉賬事務覆蓋了取款事務對存款餘額所做的更新，導致銀行最後損失了100元，相反如果轉賬事務先提交，那麼使用者賬戶將損失100元。

資料庫鎖機制
    資料併發會引發很多問題，在一些場合下有些問題是允許的，但在另外一些場合下可能卻是致命的。資料庫通過鎖的機制解決併發訪問的問題，雖然不同的資料庫在實現細節上存在差別，但原理基本上是一樣的。
    按鎖定的物件的不同，一般可以分為表鎖定和行鎖定，前者對整個表進行鎖定，而後者對錶中特定行進行鎖定。從併發事務鎖定的關係上看，可以分為共享鎖定和獨 佔鎖定。共享鎖定會防止獨佔鎖定，但允許其它的共享鎖定。而獨佔鎖定既防止其它的獨佔鎖定，也防止其它的共享鎖定。為了更改資料，資料庫必須在進行更改的 行上施加行獨佔鎖定，INSERT、UPDATE、DELETE和SELECT FOR UPDATE語句都會隱式採用必要的行鎖定。下面我們介紹一下ORACLE資料庫常用的5種鎖定：
 行共享鎖定：一般通過SELECT FOR UPDATE語句隱式獲得行共享鎖定，在Oracle中你也可以通過LOCK TABLE IN ROW SHARE MODE語句顯式獲得行共享鎖定。行共享鎖定並不防止對資料行進行更改的操作，但是可以防止其它會話獲取獨佔性資料表鎖定。允許進行多個併發的行共享和行 獨佔性鎖定，還允許進行資料表的共享或者採用共享行獨佔鎖定；
 行獨佔鎖定：通過一條INSERT、UPDATE或DELETE語句隱式獲取，或者通過一條LOCK TABLE IN ROW EXCLUSIVE MODE語句顯式獲取。這個鎖定可以防止其它會話獲取一個共享鎖定、共享行獨佔鎖定或獨佔鎖定；
 表共享鎖定：通過LOCK TABLE IN SHARE MODE語句顯式獲得。這種鎖定可以防止其它會話獲取行獨佔鎖定（INSERT、UPDATE或DELETE），或者防止其它表共享行獨佔鎖定或表獨佔鎖 定，它允許在表中擁有多個行共享和表共享鎖定。該鎖定可以讓會話具有對錶事務級一致性訪問，因為其它會話在你提交或者回溯該事務並釋放對該表的鎖定之前不 能更改這個被鎖定的表；
 表共享行獨佔：通過LOCK TABLE IN SHARE ROW EXCLUSIVE MODE語句顯式獲得。這種鎖定可以防止其它會話獲取一個表共享、行獨佔或者表獨佔鎖定，它允許其它行共享鎖定。這種鎖定類似於表共享鎖定，只是一次只能 對一個表放置一個表共享行獨佔鎖定。如果A會話擁有該鎖定，則B會話可以執行SELECT FOR UPDATE操作，但如果B會話試圖更新選擇的行，則需要等待；
 表獨佔：通過LOCK TABLE IN EXCLUSIVE MODE顯式獲得。這個鎖定防止其它會話對該表的任何其它鎖定。

事務隔離級別
    儘管資料庫為使用者提供了鎖的DML操作方式，但直接使用鎖管理是非常麻煩的，因此資料庫為使用者提供了自動鎖機制。只要使用者指定會話的事務隔離級別，資料庫 就會分析事務中的SQL語句，然後自動為事務操作的資料資源新增上適合的鎖。此外資料庫還會維護這些鎖，當一個資源上的鎖數目太多時，自動進行鎖升級以提 高系統的執行效能，而這一過程對使用者來說完全是透明的。
    ANSI/ISO SQL 92標準定義了4個等級的事務隔離級別，在相同資料環境下，使用相同的輸入，執行相同的工作，根據不同的隔離級別，可以導致不同的結果。不同事務隔離級別能夠解決的資料併發問題的能力是不同的。
        表 1 事務隔離級別對併發問題的解決情況 

隔離級別	髒讀	不可 重複讀	幻象讀	第一類丟失更新	第二類丟失更新
READ UNCOMMITED	允許	允許	允許	不允許	允許
READ COMMITTED	不允許	允許	允許	不允許	允許
REPEATABLE READ	不允許	不允許	允許	不允許	不允許
SERIALIZABLE	不允許	不允許	不允許	不允許	不允許

    事務的隔離級別和資料庫併發性是對立的，兩者此增彼長。一般來說，使用READ UNCOMMITED隔離級別的資料庫擁有最高的併發性和吞吐量，而使用SERIALIZABLE隔離級別的資料庫併發性最低。

    SQL 92定義READ UNCOMMITED主要是為了提供非阻塞讀的能力，Oracle雖然也支援READ UNCOMMITED，但它不支援髒讀，因為Oracle使用多版本機制徹底解決了在非阻塞讀時讀到髒資料的問題並保證讀的一致性，所以，Oracle的 READ COMMITTED隔離級別就已經滿足了SQL 92標準的REPEATABLE READ隔離級別。

    SQL 92推薦使用REPEATABLE READ以保證資料的讀一致性，不過使用者可以根據應用的需要選擇適合的隔離等級。

JDBC對事務的支援
    並不是所有的資料庫都支援事務，即使支援事務的資料庫也並非支援所有的事務隔離級別，你可以通過Connection# getMetaData()方法獲取DatabaseMetaData物件，並通過該物件的supportsTransactions()、 supportsTransactionIsolationLevel(int level)方法檢視底層資料庫的事務支援情況。Connection預設情況下是自動提交的，也即每條執行的SQL都對應一個事務，為了能夠將多條 SQL當成一個事務執行，必須先通過Connection#setAutoCommit(false)阻止Connection自動提交，並可通過 Connection#setTransactionIsolation()設定事務的隔離級別，Connection中定義了對應SQL 92標準4個事務隔離級別的常量。通過Connection#commit()提交事務，通過Connection#rollback()回滾事務。下面 是典型的JDBC事務資料操作的程式碼：
    程式碼清單 1 JDBC事務程式碼
Connection conn ;
try{
conn ＝ DriverManager.getConnection();①獲取資料連線
conn.setAutoCommit(false); ②關閉自動提交的機制
conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE); ③設定事務隔離級別
Statement stmt = conn.createStatement();
int rows = stmt.executeUpdate( "INSERT INTO t_topic VALUES(1,’tom’) " );
rows = stmt.executeUpdate( "UPDATE t_user set topic_nums = topic_nums +1 "+"WHERE user_id = 1");
conn.commit();④提交事務
}catch(Exception e){
…
conn.rollback();⑤提交事務
}finally{
…
}
     在JDBC 2.0中，事務最終只能有兩個操作：要麼提交要麼回滾。但是，有些應用可能需要對事務進行更多的控制，而不是簡單地提交或回滾。JDBC 3.0（JDK 1.4及以後的版本）引入了一個全新的儲存點特性，Savepoint 介面允許你將事務分割為多個階段，你可以指定回滾到事務的特定儲存點，而非象JDBC 2.0一樣只回滾到開始事務的點，如圖 1所示：

                                                                              圖 1 帶Savepoint的事務
    下面的程式碼使用了儲存點的功能，在發生特定問題時，回滾到指定的儲存點，則非回滾整個事務，如程式碼清單 2所示：
程式碼清單 2使用儲存點的事務程式碼  …
Statement stmt = conn.createStatement();
int rows = stmt.executeUpdate( "INSERT INTO t_topic VALUES(1,’tom’) " );
Savepoint svpt = conn.setSavepoint("savePoint1");①設定一個儲存點
rows = stmt.executeUpdate( "UPDATE t_user set topic_nums = topic_nums +1 "+ "WHERE user_id = 1");
…
conn.rollback(svpt); ②回滾到①處的savePoint1，①之前的SQL操作，在整個事務提交
後依然提交，但①到②之間的SQL操作被撤銷了
…
conn.commit();③提交事務


    並非所有資料庫都支援儲存點功能，你可以通過DatabaseMetaData#supportsSavepoints()方法檢視是否支援。

小結
    資料一致性和訪問的併發性兩者之間的最佳平衡永遠是資料庫應用程式開發所追求的終極目錄。資料事務是保證資料訪問一致性的不二法門，使用API進行資料庫 事務應用開發時，必須深刻了解事務控制屬性對應用效能和資料一致性兩者的影響，並根據專案實際需要進行合理的設定。

一、 資料庫事務概念

資料庫事務的特徵： ACID

Atomic （原子性）、 Consistency （一致性）、 Isolation （隔離性）和 Durability （永續性）。 DBMS 用日誌來保證資料的原子性、一致性和永續性；用鎖的機制來保證資料的隔離性。

二、 事務的邊界

資料庫支援 2 種事務模式：自動提交和手動提交。

JDBC API 的事務邊界

try
{
    Connection conn  =  java.sql.DriverManager,.getConnection(dbUrl,dbUser,dbPwd);
    conn.setAutoCommit( false );  // 設定成手動模式
    stmt  =  conn.createStatement();
    stmt.executeUpdate( " . " );  // 資料庫更新1
    stmt.executeUpdate( " . " );  // 資料庫更新2
    
    conn.commit();
}
catch (Exception e)
{
    conn.rollback();
}
finally
{
    stmt.close();
    conn.close();
}

Hibernate API 宣告事務邊界

Session session  =  factory.openSession();
Transaction tx;
try  
{
    tx  =  session.beginTransaction();  // 開始事務
     // 執行操作
    。。。。。
    
    tx.commit();
}
catch  (Exception e)
{
     if  (tx != null )
     {
        tx.rollback();
    }
}
finally
{
    session.close();
}

注：一個 session 可以對應多個事務，但是推薦的做法是一個 session 對應一個事務。

三、            多事務的併發問題

當多個事務同時訪問相同的資料的時候，程式如果沒有采取適當的隔離措施，就會發生資料庫的併發問題。常見的併發問題有：

第一類丟失更新：撤消事務的時候，把其他的事務已經提交的資料給覆蓋了；

髒讀；讀了沒有提交的資料；

虛讀：一個事務讀到另外一個事務已經提交的新插入的資料；

不可重複讀：一個事務讀到另外一個事務已經提交的更新的資料；

第二類丟失更新：一個事務覆蓋另外一個事務已經提交的更新資料。 
四、鎖

一般地，大型的 DBMS 都會自動的管理鎖定機制，但是在對資料的安全性、完整性和一致性有特殊要求的地方，可以由事務本身來管理瑣的機制。

有一點要關注的是：鎖的粒度越大，隔離性越好，併發性越差。

按照鎖的程度來分有：

共享鎖：用讀操作，非獨佔的，其他事務可以讀，但是不能更新，併發性好；

獨佔鎖：用與 insert update 和 delete 等語句，其他事務不能讀，也不能改，併發性差；

更新鎖：執行 update 的時候，加鎖。

死瑣：多是事務分別鎖定了一個資源，又請求鎖定對方已經鎖定的資源，就造成了請求環。

降低死鎖的最好辦法是使用短事務。

五、            資料庫的事務隔離級別

資料庫提供 4 種事務隔離級別：

Serializable ：序列化；（隔離級別最高） 1

Repeatable Read ：可重複讀； 2

Read Commited ：讀已提交資料； 4

Read Uncommited ：讀未提交資料；（隔離級別最低） 8

Hiberate 中的隔離級別的設定

在 Hibernate 的配置檔案中 hibernate.connection.isolation=2

六、            悲觀鎖和樂觀瑣

從應用程式的角度來看，鎖分為悲觀鎖和樂觀鎖。

悲觀鎖：顯示的為程式加鎖，但是降低併發性。

Select ……. For update;

在 Hibernate 中的程式碼

Session.get(Account.class,net Long(1),LockMode.UPGRADE) ； // 程式採用悲觀鎖

樂觀鎖：依靠 DBMS 來管理鎖，程式依靠版本控制來避免併發問題。

在物件 - 關係對映的檔案中，用 <version> 或者 <timestamp> 可以管理併發。樂觀瑣比悲觀瑣有更好的併發性，優先考慮樂觀瑣。