hibernate鎖機制包括悲觀鎖和樂觀鎖
1.悲觀鎖：
它指的是對數(shù)據(jù)被外界修改持保守態(tài)度。假定任何時刻存取數(shù)據(jù)時，都可能有另一個客戶也正在存取同一筆數(shù)據(jù)，為了保持數(shù)據(jù)被操作的一致性，于是對數(shù)據(jù)采取了
數(shù)據(jù)庫層次的
鎖定狀態(tài)，依靠
數(shù)據(jù)庫提供的鎖機制來實現(xiàn)。
基于jdbc實現(xiàn)的
數(shù)據(jù)庫加鎖如下：
select * from account where name="Erica" for update.在更新的過程中，
數(shù)據(jù)庫處于加鎖狀態(tài)，任何其他的針對本條數(shù)據(jù)的操作都將被延遲。本次事務(wù)提交后
解鎖。
而hibernate悲觀鎖的具體實現(xiàn)如下：
String sql="查詢語句";
Query query=session.createQuery(sql);
query.setLockMode("對象"，LockModel.UPGRADE);
說到這里，就提到了hiernate的加鎖模式：
LockMode.NONE ： 無鎖機制。
LockMode.WRITE ：Hibernate在Insert和Update記錄的時候會自動獲取。
LockMode.READ ： Hibernate在讀取記錄的時候會自動獲取。
這三種加鎖模式是供hibernate內(nèi)部使用的，與
數(shù)據(jù)庫加鎖無關(guān)
LockMode.UPGRADE：利用
數(shù)據(jù)庫的for update字句加鎖。
在這里我們要注意的是：只有在查詢開始之前（也就是hiernate生成sql語句之前）加鎖，才會真正通過
數(shù)據(jù)庫的鎖機制加鎖處理。否則，數(shù)據(jù)已經(jīng)通過不包含for updata子句的sql語句加載進來，所謂的
數(shù)據(jù)庫加鎖也就無從談起。
但是，從系統(tǒng)的性能上來考慮，對于單機或小系統(tǒng)而言，這并不成問題，然而如果是在網(wǎng)絡(luò)上的系統(tǒng)，同時間會有許多聯(lián)機，假設(shè)有數(shù)以百計或上千甚至更多的并發(fā)訪問出現(xiàn)，我們該怎么辦？如果等到
數(shù)據(jù)庫解鎖我們再進行下面的操作，我們浪費的資源是多少？--這也就導致了樂觀鎖的產(chǎn)生。
2.樂觀鎖：
樂觀
鎖定（optimistic locking）則樂觀的認為資料的存取很少發(fā)生同時存取的問題，因而不作
數(shù)據(jù)庫層次上的
鎖定，為了維護正確的數(shù)據(jù)，樂觀
鎖定采用應(yīng)用程序上的邏輯實現(xiàn)版本控制的方法。
例如若有兩個客戶端，A客戶先讀取了賬戶余額100元，之后B客戶也讀取了賬戶余額100元的數(shù)據(jù)，A客戶提取了50元，對
數(shù)據(jù)庫作了變更，此時
數(shù)據(jù)庫中的余額為50元，B客戶也要提取30元，根據(jù)其所取得的資料，100-30將為70余額，若此時再對
數(shù)據(jù)庫進行變更，最后的余額就會不正確。
在不實行悲觀
鎖定策略的情況下，數(shù)據(jù)不一致的情況一但發(fā)生，有幾個解決的方法，一種是先更新為主，一種是后更新的為主，比較復(fù)雜的就是檢查發(fā)生變動的數(shù)據(jù)來實現(xiàn)，或是檢查所有屬性來實現(xiàn)樂觀
鎖定。
Hibernate 中透過版本號檢查來實現(xiàn)后更新為主，這也是Hibernate所推薦的方式，在
數(shù)據(jù)庫中加入一個VERSON欄記錄，在讀取數(shù)據(jù)時連同版本號一同讀取，并在更新數(shù)據(jù)時遞增版本號，然后比對版本號與
數(shù)據(jù)庫中的版本號，如果大于
數(shù)據(jù)庫中的版本號則予以更新，否則就回報錯誤。
以剛才的例子，A客戶讀取賬戶余額1000元，并連帶讀取版本號為5的話，B客戶此時也讀取賬號余額1000元，版本號也為5，A客戶在領(lǐng)款后賬戶余額為500，此時將版本號加1，版本號目前為6，而
數(shù)據(jù)庫中版本號為5，所以予以更新，更新
數(shù)據(jù)庫后，
數(shù)據(jù)庫此時余額為500，版本號為6，B客戶領(lǐng)款后要變更
數(shù)據(jù)庫，其版本號為5，但是
數(shù)據(jù)庫的版本號為6，此時不予更新，B客戶數(shù)據(jù)重新讀取
數(shù)據(jù)庫中新的數(shù)據(jù)并重新進行業(yè)務(wù)流程才變更
數(shù)據(jù)庫。
以Hibernate實現(xiàn)版本號控制
鎖定的話，我們的對象中增加一個version屬性，例如：
<public class Account {
private int version;
....
public void setVersion(int version) {
this.version = version;
}
public int getVersion() {
return version;
}
....
}
而在映像文件中，我們使用optimistic-lock屬性設(shè)定version控制，<id>屬性欄之后增加一個<version>標簽，如下：
<hibernate-mapping>
<class name="onlyfun.caterpillar.Account" talble="ACCOUNT"
optimistic-lock="version">
<id...../>
<version name="version" column="VERSION"/>
....
</class>
</hibernate-mapping>
設(shè)定好版本控制之后，在上例中如果B 客戶試圖更新數(shù)據(jù)，將會引發(fā)StableObjectStateException例外，我們可以捕捉這個例外，在處理中重新讀取
數(shù)據(jù)庫中的數(shù)據(jù)，同時將 B客戶目前的數(shù)據(jù)與
數(shù)據(jù)庫中的數(shù)據(jù)秀出來，讓B客戶有機會比對不一致的數(shù)據(jù)，以決定要變更的部份，或者您可以設(shè)計程式自動讀取新的資料，并重復(fù)扣款業(yè)務(wù)流程，直到數(shù)據(jù)可以更新為止，這一切可以在背景執(zhí)行，而不用讓您的客戶知道。
但是樂觀鎖也有不能解決的問題存在：上面已經(jīng)提到過樂觀鎖機制的實現(xiàn)往往基于系統(tǒng)中的數(shù)據(jù)存儲邏輯，在我們的系統(tǒng)中實現(xiàn)，來自外部系統(tǒng)的用戶余額更新不受我們系統(tǒng)的控制，有可能造成非法數(shù)據(jù)被更新至
數(shù)據(jù)庫。因此我們在做電子商務(wù)的時候，一定要小心的注意這項存在的問題，采用比較合理的邏輯驗證，避免數(shù)據(jù)執(zhí)行錯誤。
也可以在使用Session的load()或是lock()時指定
鎖定模式以進行
鎖定。
如果
數(shù)據(jù)庫不支持所指定的
鎖定模式，Hibernate會選擇一個合適的
鎖定替換，而不是丟出一個例外。