hibernate 鎖機制

Hibernate 悲觀鎖,樂觀鎖 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控制，<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會選擇一個合適的鎖定替換，而不是丟出一個例外。

轉載：http://www.cnblogs.com/wblade/archive/2011/05/11/2042963.html