Hibernate事務與并發(fā)問題處理
一、數(shù)據(jù)庫事務的定義
數(shù)據(jù)庫事務(Database Transaction) ，是指作為單個邏輯工作單元執(zhí)行的一系列操作。事務處理可以確保除非事務性單元內(nèi)的所有操作都成功完成，否則不會***更新面向數(shù)據(jù)的資源。通過將一組相關操作組合為一個要么全部成功要么全部失敗的單元，可以簡化錯誤恢復并使應用程序更加可靠。一個邏輯工作單元要成為事務，必須滿足所謂的ACID(原子性、一致性、隔離性和持久性)屬性。
1. 原子性(atomic)，事務必須是原子工作單元；對于其數(shù)據(jù)修改，要么全都執(zhí)行，要么全都不執(zhí)行
2. 一致性(consistent)，事務在完成時，必須使所有的數(shù)據(jù)都保持一致狀態(tài)。
3. 隔離性(insulation)，由并發(fā)事務所作的修改必須與任何其它并發(fā)事務所作的修改隔離。
4. 持久性(Duration)，事務完成之后，它對于系統(tǒng)的影響是***性的。
二、數(shù)據(jù)庫事務并發(fā)可能帶來的問題
如果沒有鎖定且多個用戶同時訪問一個數(shù)據(jù)庫，則當他們的事務同時使用相同的數(shù)據(jù)時可能會發(fā)生問題。由于并發(fā)操作帶來的數(shù)據(jù)不一致性包括：丟失數(shù)據(jù)修改、讀”臟”數(shù)據(jù)（臟讀）、不可重復讀、產(chǎn)生幽靈數(shù)據(jù)：
假設數(shù)據(jù)庫中有如下一張表：
1. ***類丟失更新(lost update)： 在完全未隔離事務的情況下，兩個事物更新同一條數(shù)據(jù)資源，某一事物異常終止，回滾造成***個完成的更新也同時丟失。
在T1時刻開啟了事務1，T2時刻開啟了事務2，在T3時刻事務1從數(shù)據(jù)庫中取出了 id="402881e535194b8f0135194b91310001"的數(shù)據(jù)，T4時刻事務2取出了同一條數(shù)據(jù)，T5時刻事務1將age字段值更新為30，T6時刻事務2更新age為35并提交了數(shù)據(jù)，但是T7事務1回滾了事務age***的值依然為20，事務2的更新丟失了，這種情況就叫做"***類丟失更新(lost update)"。
2. 臟讀(dirty read)：如果第二個事務查詢到***個事務還未提交的更新數(shù)據(jù)，形成臟讀。
在T1時刻開啟了事務1，T2時刻開啟了事務2，在T3時刻事務1從數(shù)據(jù)庫中取出了id="402881e535194b8f0135194b91310001"的數(shù)據(jù)，在T5時刻事務1將age的值更新為30，但是事務還未提交，T6時刻事務2讀取同一條記錄，獲得age的值為30，但是事務1還未提交，若在T7時刻事務1回滾了事務2的數(shù)據(jù)就是錯誤的數(shù)據(jù)(臟數(shù)據(jù))，這種情況叫做" 臟讀(dirty read)"。
3. 虛讀(phantom read)：一個事務執(zhí)行兩次查詢，第二次結果集包含***次中沒有或者某些行已被刪除，造成兩次結果不一致，只是另一個事務在這兩次查詢中間插入或者刪除了數(shù)據(jù)造成的。
在T1時刻開啟了事務1，T2時刻開啟了事務2，T3時刻事務1從數(shù)據(jù)庫中查詢所有記錄，記錄總共有一條，T4時刻事務2向數(shù)據(jù)庫中插入一條記錄，T6時刻事務2提交事務。T7事務1再次查詢數(shù)據(jù)數(shù)據(jù)時，記錄變成兩條了。這種情況是"虛讀(phantom read)"。
4. 不可重復讀(unrepeated read)：一個事務兩次讀取同一行數(shù)據(jù)，結果得到不同狀態(tài)結果，如中間正好另一個事務更新了該數(shù)據(jù)，兩次結果相異，不可信任。
在T1時刻開啟了事務1，T2時刻開啟了事務2，在T3時刻事務1從數(shù)據(jù)庫中取出了 id="402881e535194b8f0135194b91310001"的數(shù)據(jù)，此時age=20，T4時刻事務2查詢同一條數(shù)據(jù)，T5事務2更新數(shù)據(jù)age=30，T6時刻事務2提交事務，T7事務1查詢同一條數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)與***次不一致。這種情況就是"不可重復讀(unrepeated read)"。
5. 第二類丟失更新(second lost updates)：是不可重復讀的特殊情況，如果兩個事務都讀取同一行，然后兩個都進行寫操作，并提交，***個事務所做的改變就會丟失。
在T1時刻開啟了事務1，T2時刻開啟了事務2，T3時刻事務1更新數(shù)據(jù)age=25，T5時刻事務2更新數(shù)據(jù)age=30，T6時刻提交事務，T7時刻事務2提交事務，把事務1的更新覆蓋了。這種情況就是"第二類丟失更新(second lost updates)"。
三、數(shù)據(jù)庫事務隔離級別
為了解決數(shù)據(jù)庫事務并發(fā)運行時的各種問題數(shù)據(jù)庫系統(tǒng)提供四種事務隔離級別：
1. Serializable 串行化
2. Repeatable Read 可重復讀
3. Read Commited 可讀已提交
4. Read Uncommited 可讀未提交
隔離級別與并發(fā)性能的關系：
每一個隔離級別可以解決的問題：
四、使用Hibernate設置數(shù)據(jù)庫隔離級別
在Hibernate的配置文件中可以顯示的配置數(shù)據(jù)庫事務隔離級別。每一個隔離級別用一個整數(shù)表示：
8 - Serializable 串行化
4 - Repeatable Read 可重復讀
2 - Read Commited 可讀已提交
1 - Read Uncommited 可讀未提交
在hibernate.cfg.xml中使用hibernate.connection.isolation參數(shù)配置數(shù)據(jù)庫事務隔離級別。
五、使用悲觀鎖解決事務并發(fā)問題
悲觀鎖，正如其名，它指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當前的其他事務，以及來自外部系統(tǒng)的事務處理）修改持保守態(tài)度，因此，在整個數(shù)據(jù)處理過程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機制（也只有數(shù)據(jù)庫層提供的鎖機制才能真正保證數(shù)據(jù)訪問的排他性，否則，即使在本系統(tǒng)中實現(xiàn)了加鎖機制，也無法保證外部系統(tǒng)不會修改數(shù)據(jù)）。
一個典型的依賴數(shù)據(jù)庫的悲觀鎖調(diào)用：select * from account where name=”Erica” for update這條 sql 語句鎖定了 account 表中所有符合檢索條件（ name=”Erica” ）的記錄。本次事務提交之前（事務提交時會釋放事務過程中的鎖），外界無法修改這些記錄。悲觀鎖，也是基于數(shù)據(jù)庫的鎖機制實現(xiàn)。
在Hibernate使用悲觀鎖十分容易，但實際應用中悲觀鎖是很少被使用的，因為它大大限制了并發(fā)性：
圖為Hibernate3.6的幫助文檔Session文檔的get方法截圖，可以看到get方法第三個參數(shù)"lockMode" 或"lockOptions"，注意在Hibernate3.6以上的版本中"LockMode"已經(jīng)不建議使用。方法的第三個參數(shù)就是用來設置悲觀鎖的，使用第三個參數(shù)之后，我們每次發(fā)送的SQL語句都會加上"for update"用于告訴數(shù)據(jù)庫鎖定相關數(shù)據(jù)。
LockMode參數(shù)選擇該選項，就會開啟悲觀鎖。
T1,T2時刻取款事務和轉賬事務分別開啟，T3事務查詢ACCOUNTS表的數(shù)據(jù)并用悲觀鎖鎖定，T4轉賬事務也要查詢同一條數(shù)據(jù)，數(shù)據(jù)庫發(fā)現(xiàn)該記錄已經(jīng)被前一個事務使用悲觀鎖鎖定了，然后讓轉賬事務等待直到取款事務提交。T6時刻取款事務提交，T7時刻轉賬事務獲取數(shù)據(jù)。
六、使用樂觀鎖解決事務并發(fā)問題
相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。悲觀鎖大多數(shù)情況下依靠數(shù)據(jù)庫的鎖機制實現(xiàn)，以保證操作***程度的獨占性。但隨之而來的就是數(shù)據(jù)庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基于數(shù)據(jù)版本（Version）記錄機制實現(xiàn)。何謂數(shù)據(jù)版本？即為數(shù)據(jù)增加一個版本標識，在基于數(shù)據(jù)庫表的版本解決方案中，一般是通過為數(shù)據(jù)庫表增加一個"version"字段來實現(xiàn)。
樂觀鎖的工作原理：讀取出數(shù)據(jù)時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)庫表對應記錄的當前版本信息進行比對，如果提交的數(shù)據(jù)版本號大于數(shù)據(jù)庫表當前版本號，則予以更新，否則認為是過期數(shù)據(jù)。
Hibernate為樂觀鎖提供了3中實現(xiàn)：
1. 基于version
2. 基于timestamp
3. 為遺留項目添加添加樂觀鎖
配置基于version的樂觀鎖：
- <?xml version="1.0" encoding="utf-8"?>
- <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
- <hibernate-mapping>
- <class name="com.suxiaolei.hibernate.pojos.People" table="people">
- <id name="id" type="string">
- <column name="id"></column>
- <generator class="uuid"></generator>
- </id>
- <!-- version標簽用于指定表示版本號的字段信息 -->
- <version name="version" column="version" type="integer"></version>
- <property name="name" column="name" type="string"></property>
- </class>
- </hibernate-mapping>
配置基于timestamp的樂觀鎖：
- <?xml version="1.0" encoding="utf-8"?>
- <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
- <hibernate-mapping>
- <class name="com.suxiaolei.hibernate.pojos.People" table="people">
- <id name="id" type="string">
- <column name="id"></column>
- <generator class="uuid"></generator>
- </id>
- <!-- timestamp標簽用于指定表示版本號的字段信息 -->
- <timestamp name="updateDate" column="updateDate"></timestamp>
- <property name="name" column="name" type="string"></property>
- </class>
- </hibernate-mapping>
遺留項目，由于各種原因無法為原有的數(shù)據(jù)庫添加"version"或"timestamp"字段，這時不可以使用上面兩種方式配置樂觀鎖，Hibernate為這種情況提供了一個"optimisitic-lock"屬性，它位于<class>標簽上：
- <?xml version="1.0" encoding="utf-8"?>
- <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
- <hibernate-mapping>
- <class name="com.suxiaolei.hibernate.pojos.People" table="people" optimistic-lock="all">
- <id name="id" type="string">
- <column name="id"></column>
- <generator class="uuid"></generator>
- </id>
- <property name="name" column="name" type="string"></property>
- </class>
- </hibernate-mapping>
將該屬性的值設置為all，讓該記錄所有的字段都為版本控制信息。
原文鏈接：http://www.cnblogs.com/otomedaybreak/archive/2012/01/27/2330008.html#C2
【編輯推薦】
