Hibernate鎖機制 悲觀鎖、樂觀鎖

悲觀鎖

        它指的是對資料被外界修改持保守态度。假定任何時刻存取資料時，都可能有另一個客戶也正在存取同一筆資料，為了保持資料被操作的一緻性，于是對資料采取了資料庫層次的鎖定狀态，依靠資料庫提供的鎖機制來實作。 基于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字句加鎖。 這種模式需要區分前三種模式，該模式是與資料有關的（for update）

在這裡我們要注意的是：隻有在查詢開始之前（也就是hiernate生成sql語句之前）加鎖，才會真正通過資料庫的鎖機制加鎖處理。否則，資料已經通過不包含for updata子句的sql語句加載進來，所謂的資料庫加鎖也就無從談起。 但是，從系統的性能上來考慮，對于單機或小系統而言，這并不成問題，然而如果是在網絡上的系統，同時間會有許多聯機，假設有數以百計或上千甚至更多的并發通路出現，我們該怎麼辦？如果等到資料庫解鎖我們再進行下面的操作，我們浪費的資源是多少？--這也就導緻了樂觀鎖的産生。 

樂觀鎖 

        樂觀鎖定（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控制，<id>屬性欄之後增加一個<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會選擇一個合适的鎖定替換，而不是丢出一個例外。

未完待續。。。。