Hibernate之悲觀鎖和樂觀鎖

hibernate之悲觀鎖和樂觀鎖

悲觀鎖悲觀鎖的實現，通常依賴於資料庫機制，在整個過程中將資料鎖定，其它任何使用者都不能讀取或修改.這種策略的併發性不好。

下面以庫存量為例，有倆個使用者去庫里取東西。

第一步首先寫出實體類：

public class inventory

第二步，編寫實體關係類的對映檔案：

第三步編寫hibernate配置檔案：

jdbc:mysql://localhost/hibernate_pessimistic_locking

com.mysql.jdbc.driver

root

bjsxt

org.hibernate.dialect.mysqldialect

true

第四步,編寫測試檔案：

我們先寫乙個輸入輸入的類：

public static void main(string args) catch(exception e) finally }}

接著寫倆個使用者去取資料的類:

public class pessimisticlockingtest extends testcase catch(exception e) finally

}public void testload2() catch(exception e) finally }}

樂觀鎖樂觀鎖其實不是鎖，他是一種衝突檢測手段。大多數基於資料版本記錄機制（version）實現，一般是在資料庫表中加入乙個version欄位

讀取資料時將版本號一同讀出，之後更新資料時版本號加一，如果提交資料時版本號小於或等於資料表中

的版本號，則認為資料是過期的，否則給予更新

樂觀鎖的併發性比較好。

我們還以上面的例子為例來說明樂觀鎖。

首先建立實體類：

public class inventory

第二步寫實體類的對映檔案：

//這個必須配在主鍵的宣告後面，這個欄位不需要我們去維護，是由hibernate自己去維護的

第三步寫hibernate配置檔案：

jdbc:mysql://localhost/hibernate_optimistic_locking

com.mysql.jdbc.driver

root

bjsxt

org.hibernate.dialect.mysqldialect

true

第四步寫測試**：

還是寫乙個新增資料的類：

public class initdata catch(exception e) finally }}

下面加入倆個使用者：

public class optimisticlockingtest extends testcase

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 
public int getversion() 
....
}

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

設定好版本控制之後，在上例中如果b 客戶試圖更新資料，將會引發stableobjectstateexception例外，我們可以捕捉這個例外，在處理中重新讀取資料庫中的資料，同時將 b客戶目前的資料與資料庫中的資料秀出來，讓b客戶有機會比對不一致的資料，以決定要變更的部份，或者您可以設計程式自動讀取新的資料，並重複扣款業務流程，直到資料可以更新為止，這一切可以在背景執行，而不用讓您的客戶知道。

但是樂觀鎖也有不能解決的問題存在：上面已經提到過樂觀鎖機制的實現往往基於系統中的資料儲存邏輯，在我們的系統中實現，來自外部系統的使用者餘額更新不受我們系統的控制，有可能造成非法資料被更新至資料庫。因此我們在做電子商務的時候，一定要小心的注意這項存在的問題，採用比較合理的邏輯驗證，避免資料執行錯誤。

也可以在使用session的load()或是lock()時指定鎖定模式以進行鎖定。

如果資料庫不支援所指定的鎖定模式，hibernate會選擇乙個合適的鎖定替換，而不是丟出乙個例外。

Hibernate之悲觀鎖和樂觀鎖

hibernate悲觀鎖和樂觀鎖

hibernate悲觀鎖和樂觀鎖

Hibernate 悲觀鎖和樂觀鎖

Hibernate之悲觀鎖和樂觀鎖

hibernate悲觀鎖和樂觀鎖

hibernate悲觀鎖和樂觀鎖

Hibernate 悲觀鎖和樂觀鎖

相關推薦