Hibernate JPA 悲觀鎖,樂觀鎖

1.悲觀鎖

它指的是對數據被外界修改持保守態度。假定任何時刻存取數據時，都可能有另一個客戶也正在存取同一筆數據，爲了保持數據被操作的一致性，於是對數據採取了數據庫層次的鎖定狀態，依靠數據庫提供的鎖機制來實現。 
基於jdbc實現的數據庫加鎖如下：

select * from account where name="Erica" for update

在更新的過程中，數據庫處於加鎖狀態，任何其他的針對本條數據的操作都將被延遲。本次事務提交後解鎖。 
而hibernate悲觀鎖的具體實現如下：

String sql="查詢語句";
Query query=session.createQuery(sql);
query.setLockMode("對象"，LockModel.UPGRADE);

說到這裏，就提到了hibernate的加鎖模式：

• LockMode.NONE：無鎖機制。
• LockMode.WRITE：Hibernate在Insert和Update記錄的時候會自動獲取。
• LockMode.READ：Hibernate在讀取記錄的時候會自動獲取。

這三種加鎖模式是供hibernate內部使用的，與數據庫加鎖無關： 
LockMode.UPGRADE：利用數據庫的for update字句加鎖。 
在這裏我們要注意的是：只有在查詢開始之前（也就是hiernate生成sql語句之前）加鎖，纔會真正通過數據庫的鎖機制加鎖處理。否則，數據已經通過不包含for updata子句的sql語句加載進來，所謂的數據庫加鎖也就無從談起。 
但 是，從系統的性能上來考慮，對於單機或小系統而言，這並不成問題，然而如果是在網絡上的系統，同時間會有許多聯機，假設有數以百計或上千甚至更多的併發訪 問出現，我們該怎麼辦？如果等到數據庫解鎖我們再進行下面的操作，我們浪費的資源是多少？–這也就導致了樂觀鎖的產生。

2.樂觀鎖

樂觀鎖定（optimistic locking）則樂觀的認爲資料的存取很少發生同時存取的問題，因而不作數據庫層次上的鎖定，爲了維護正確的數據，樂觀鎖定採用應用程序上的邏輯實現版本控制的方法。 
例如若有兩個客戶端，A客戶先讀取了賬戶餘額100元，之後B客戶也讀取了賬戶餘額100元的數據，A客戶提取了50元，對數據庫作了變更，此時數 據庫中的餘額爲50元，B客戶也要提取30元，根據其所取得的資料，100-30將爲70餘額，若此時再對數據庫進行變更，最後的餘額就會不正確。 
在不實行悲觀鎖定策略的情況下，數據不一致的情況一但發生，有幾個解決的方法，一種是先更新爲主，一種是後更新的爲主，比較複雜的就是檢查發生變動的數據來實現，或是檢查所有屬性來實現樂觀鎖定。 
Hibernate 中透過版本號檢查來實現後更新爲主，這也是Hibernate所推薦的方式，在數據庫中加入一個VERSON欄記錄，在讀取數 據時連同版本號一同讀取，並在更新數據時遞增版本號，然後比對版本號與數據庫中的版本號，如果大於數據庫中的版本號則予以更新，否則就回報錯誤。 
以剛纔的例子，A客戶讀取賬戶餘額1000元，並連帶讀取版本號爲5的話，B客戶此時也讀取賬號餘額1000元，版本號也爲5，A客戶在領款後賬戶 餘額爲500，此時將版本號加1，版本號目前爲6，而數據庫中版本號爲5，所以予以更新，更新數據庫後，數據庫此時餘額爲500，版本號爲6，B客戶領款 後要變更數據庫，其版本號爲5，但是數據庫的版本號爲6，此時不予更新，B客戶數據重新讀取數據庫中新的數據並重新進行業務流程才變更數據庫。 
以Hibernate實現版本號控制鎖定的話，我們的對象中增加一個version屬性，例如：

public class Account {
private int version;
....
public void setVersion(int version) {
this.version = version;
}
public int getVersion() {
return version;
}
....
}

而在映像文件中，我們使用optimistic-lock屬性設定version控制，屬性欄之後增加一個標籤，如下：

<hibernate-mapping>
<class name="onlyfun.caterpillar.Account" talble="ACCOUNT"
optimistic-lock="version">
<id...../>
<version name="version" column="VERSION"/>
....
</class>
</hibernate-mapping>

設定好版本控制之後，在上例中如果B 客戶試圖更新數據，將會引發StableObjectStateException例外，我們可以捕捉這個例 外，在處理中重新讀取數據庫中的數據，同時將 B客戶目前的數據與數據庫中的數據秀出來，讓B客戶有機會比對不一致的數據，以決定要變更的部份，或者您可 以設計程式自動讀取新的資料，並重復扣款業務流程，直到數據可以更新爲止，這一切可以在背景執行，而不用讓您的客戶知道。 
但是樂觀鎖也有不能解決的問題存在：上面已經提到過樂觀鎖機制的實現往往基於系統中的數據存儲邏輯，在我們的系統中實現，來自外部系統的用戶餘額更 新不受我們系統的控制，有可能造成非法數據被更新至數據庫。因此我們在做電子商務的時候，一定要小心的注意這項存在的問題，採用比較合理的邏輯驗證，避免 數據執行錯誤。 
也可以在使用Session的load()或是lock()時指定鎖定模式以進行鎖定。 
如果數據庫不支持所指定的鎖定模式，Hibernate會選擇一個合適的鎖定替換，而不是丟出一個例外。

悲觀鎖與樂觀鎖的比較:

悲觀鎖大多數情況下依靠數據庫的鎖機制實現，以保證操作最大程度的獨佔性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受; 
相對悲觀鎖而言，樂觀鎖機制採取了更加寬鬆的加鎖機制。樂觀鎖機制往往基於系統中的數據存儲邏輯，因此也具備一定的侷限性，如在上例中，由於樂觀鎖機制是在我們的系統中實現，來自外部系統的更新操作不受我們系統的控制，因此可能會造成髒數據被更新到數據庫中。在系統設計階段，我們應該充分考慮到這些情況出現的可能性，並進行相應調整（如將樂觀鎖策略在數據庫存儲過程中實現，對外只開放基於此存儲過程的數據更新途徑，而不是將數據庫表直接對外公開）。 
Hibernate 在其數據訪問引擎中內置了樂觀鎖實現。如果不用考慮外部系統對數據庫的更新操作，利用Hibernate提供的透明化樂觀鎖實現，將大大提升我們的生產力。

Hibernate中可以通過class描述符的optimistic-lock屬性結合version描述符指定。 
optimistic-lock屬性有如下可選取值： 
- none 無樂觀鎖 
- version 通過版本機制實現樂觀鎖 
- dirty 通過檢查發生變動過的屬性實現樂觀鎖 
- all 通過檢查所有屬性實現樂觀鎖

其中通過version實現的樂觀鎖機制是Hibernate官方推薦的樂觀鎖實現，同時也是Hibernate中，目前唯一在數據對象脫離Session發生修改的情況下依然有效的鎖機制。因此，一般情況下，我們都選擇version方式作爲Hibernate樂觀鎖實現機制。

JPA 2.0 鎖機制

鎖是處理數據庫事務併發的一種技術，當兩個或更多數據庫事務併發地訪問相同數據時，鎖可以保證同一時間只有一個事務可以修改數據。 
鎖的方法通常有兩種：樂觀鎖和悲觀鎖。樂觀鎖認爲多個併發事務之間很少出現衝突，也就是說不會經常出現同一時間讀取或修改相同數據，在樂觀鎖中，其目標是讓併發事務自由地同時得到處理，而不是發現或預防衝突。兩個事務在同一時刻可以訪問相同的數據，但爲了預防衝突，需要對數據執行一次檢查，檢查自上次讀取數據以來發生的任何變化。 
悲觀鎖認爲事務會經常發生衝突，在悲觀鎖中，讀取數據的事務會鎖定數據，在前面的事務提交之前，其它事務都不能修改數據。 
JPA 1.0只支持樂觀鎖，你可以使用EntityManager類的lock()方法指定鎖模式的值，可以是READ或WRITE，如：

EntityManagerem = ... ;
em.lock (p1, READ);

對於READ鎖模式，JPA實體管理器在事務提交前都會鎖定實體，檢查實體的版本屬性確定實體自上次被讀取以來是否有更新，如果版本屬性被更新了，實體管理器會拋出一個OptimisticLockException異常，並回滾事務。 
對於WRITE鎖模式，實體管理器執行和READ鎖模式相同的樂觀鎖操作，但它也會更新實體的版本列。 
JPA 2.0增加了6種新的鎖模式，其中兩個是樂觀鎖。JPA 2.0也允許悲觀鎖，並增加了3種悲觀鎖，第6種鎖模式是無鎖。 
下面是新增的兩個樂觀鎖模式： 
1、OPTIMISTIC：它和READ鎖模式相同，JPA 2.0仍然支持READ鎖模式，但明確指出在新應用程序中推薦使用OPTIMISTIC。 
2、OPTIMISTIC_FORCE_INCREMENT：它和WRITE鎖模式相同，JPA 2.0仍然支持WRITE鎖模式，但明確指出在新應用程序中推薦使用OPTIMISTIC_FORCE_INCREMENT。 
下面是新增的三個悲觀鎖模式： 
1、PESSIMISTIC_READ：只要事務讀實體，實體管理器就鎖定實體，直到事務完成鎖纔會解開，當你想使用重複讀語義查詢數據時使用這種鎖模式，換句話說就是，當你想確保數據在連續讀期間不被修改，這種鎖模式不會阻礙其它事務讀取數據。 
2、PESSIMISTIC_WRITE：只要事務更新實體，實體管理器就會鎖定實體，這種鎖模式強制嘗試修改實體數據的事務串行化，當多個併發更新事務出現更新失敗機率較高時使用這種鎖模式。 
3、PESSIMISTIC_FORCE_INCREMENT：當事務讀實體時，實體管理器就鎖定實體，當事務結束時會增加實體的版本屬性，即使實體沒有修改。 
你也可以指定新的鎖模式NONE，在這種情況下表示沒有鎖發生。 
JPA 2.0也提供了多種方法爲實體指定鎖模式，你可以使用EntityManager的lock() 和 find()方法指定鎖模式。此外，EntityManager.refresh()方法可以恢復實體實例的狀態。 
下面的代碼顯示了使用PESSIMISTIC_WRITE鎖模式的悲觀鎖：

    // read
    Part p = em.find(Part.class, pId);
    // lock and refresh before update
    em.refresh(p, PESSIMISTIC_WRITE);
    int pAmount = p.getAmount();
    p.setAmount(pAmount - uCount); 

在這個例子中，它首先讀取一些數據，然後應用PESSIMISTIC_WRITE鎖，在更新數據之前調用EntityManager.refresh()方法，當事務更新實體時，PESSIMISTIC_WRITE鎖鎖定實體，其它事務就不能更新相同的實體，直到前面的事務提交。