hibernate鎖機(jī)制包括悲觀鎖和樂觀鎖
1.悲觀鎖：
???它指的是對(duì)數(shù)據(jù)被外界修改持保守態(tài)度。假定任何時(shí)刻存取數(shù)據(jù)時(shí)，都可能有另一個(gè)客戶也正在

存取同一筆數(shù)據(jù)，為了保持?jǐn)?shù)據(jù)被操作的一致性，于是對(duì)數(shù)據(jù)采取了數(shù)據(jù)庫層次的鎖定狀態(tài)，依靠數(shù)

據(jù)庫提供的鎖機(jī)制來實(shí)現(xiàn)。

???基于jdbc實(shí)現(xiàn)的數(shù)據(jù)庫加鎖如下：
???select?*?from?account?where?name="Erica"?for?update.在更新的過程中，數(shù)據(jù)庫處于加鎖狀

態(tài)，任何其他的針對(duì)本條數(shù)據(jù)的操作都將被延遲。本次事務(wù)提交后解鎖。

???而hibernate悲觀鎖的具體實(shí)現(xiàn)如下：
???String?sql="查詢語句";
???Query?query=session.createQuery(sql);
???query.setLockMode("對(duì)象"，LockModel.UPGRADE);

???說到這里，就提到了hiernate的加鎖模式：
???LockMode.NONE?：?無鎖機(jī)制。
???LockMode.WRITE?：Hibernate在Insert和Update記錄的時(shí)候會(huì)自動(dòng)獲取。
???LockMode.READ?：?Hibernate在讀取記錄的時(shí)候會(huì)自動(dòng)獲取。
???這三種加鎖模式是供hibernate內(nèi)部使用的，與數(shù)據(jù)庫加鎖無關(guān)
???LockMode.UPGRADE：利用數(shù)據(jù)庫的for?update字句加鎖。
???在這里我們要注意的是：只有在查詢開始之前（也就是hiernate生成sql語句之前）加鎖，才會(huì)真

正通過數(shù)據(jù)庫的鎖機(jī)制加鎖處理。否則，數(shù)據(jù)已經(jīng)通過不包含for?updata子句的sql語句加載進(jìn)來，

所謂的數(shù)據(jù)庫加鎖也就無從談起。

???但是，從系統(tǒng)的性能上來考慮，對(duì)于單機(jī)或小系統(tǒng)而言，這并不成問題，然而如果是在網(wǎng)絡(luò)上的

系統(tǒng)，同時(shí)間會(huì)有許多聯(lián)機(jī)，假設(shè)有數(shù)以百計(jì)或上千甚至更多的并發(fā)訪問出現(xiàn)，我們?cè)撛趺崔k？如果

等到數(shù)據(jù)庫解鎖我們?cè)龠M(jìn)行下面的操作，我們浪費(fèi)的資源是多少？--這也就導(dǎo)致了樂觀鎖的產(chǎn)生。
??2.樂觀鎖：
　樂觀鎖定（optimistic?locking）則樂觀的認(rèn)為資料的存取很少發(fā)生同時(shí)存取的問題，因而不作數(shù)

據(jù)庫層次上的鎖定，為了維護(hù)正確的數(shù)據(jù)，樂觀鎖定采用應(yīng)用程序上的邏輯實(shí)現(xiàn)版本控制的方法。
　例如若有兩個(gè)客戶端，A客戶先讀取了賬戶余額100元，之后B客戶也讀取了賬戶余額100元的數(shù)據(jù)，

A客戶提取了50元，對(duì)數(shù)據(jù)庫作了變更，此時(shí)數(shù)據(jù)庫中的余額為50元，B客戶也要提取30元，根據(jù)其所

取得的資料，100-30將為70余額，若此時(shí)再對(duì)數(shù)據(jù)庫進(jìn)行變更，最后的余額就會(huì)不正確。
　在不實(shí)行悲觀鎖定策略的情況下，數(shù)據(jù)不一致的情況一但發(fā)生，有幾個(gè)解決的方法，一種是先更新

為主，一種是后更新的為主，比較復(fù)雜的就是檢查發(fā)生變動(dòng)的數(shù)據(jù)來實(shí)現(xiàn)，或是檢查所有屬性來實(shí)現(xiàn)

樂觀鎖定。
　Hibernate?中透過版本號(hào)檢查來實(shí)現(xiàn)后更新為主，這也是Hibernate所推薦的方式，在數(shù)據(jù)庫中加

入一個(gè)VERSON欄記錄，在讀取數(shù)據(jù)時(shí)連同版本號(hào)一同讀取，并在更新數(shù)據(jù)時(shí)遞增版本號(hào)，然后比對(duì)版

本號(hào)與數(shù)據(jù)庫中的版本號(hào)，如果大于數(shù)據(jù)庫中的版本號(hào)則予以更新，否則就回報(bào)錯(cuò)誤。
　以剛才的例子，A客戶讀取賬戶余額1000元，并連帶讀取版本號(hào)為5的話，B客戶此時(shí)也讀取賬號(hào)余

額1000元，版本號(hào)也為5，A客戶在領(lǐng)款后賬戶余額為500，此時(shí)將版本號(hào)加1，版本號(hào)目前為6，而數(shù)

據(jù)庫中版本號(hào)為5，所以予以更新，更新數(shù)據(jù)庫后，數(shù)據(jù)庫此時(shí)余額為500，版本號(hào)為6，B客戶領(lǐng)款后

要變更數(shù)據(jù)庫，其版本號(hào)為5，但是數(shù)據(jù)庫的版本號(hào)為6，此時(shí)不予更新，B客戶數(shù)據(jù)重新讀取數(shù)據(jù)庫

中新的數(shù)據(jù)并重新進(jìn)行業(yè)務(wù)流程才變更數(shù)據(jù)庫。
　以Hibernate實(shí)現(xiàn)版本號(hào)控制鎖定的話，我們的對(duì)象中增加一個(gè)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>屬性欄之后增加一個(gè)

<version>標(biāo)簽，如下：

<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ù)，將會(huì)引發(fā)StableObjectStateException

例外，我們可以捕捉這個(gè)例外，在處理中重新讀取數(shù)據(jù)庫中的數(shù)據(jù)，同時(shí)將?B客戶目前的數(shù)據(jù)與數(shù)據(jù)

庫中的數(shù)據(jù)秀出來，讓B客戶有機(jī)會(huì)比對(duì)不一致的數(shù)據(jù)，以決定要變更的部份，或者您可以設(shè)計(jì)程式

自動(dòng)讀取新的資料，并重復(fù)扣款業(yè)務(wù)流程，直到數(shù)據(jù)可以更新為止，這一切可以在背景執(zhí)行，而不用

讓您的客戶知道。
???但是樂觀鎖也有不能解決的問題存在：上面已經(jīng)提到過樂觀鎖機(jī)制的實(shí)現(xiàn)往往基于系統(tǒng)中的數(shù)據(jù)

存儲(chǔ)邏輯，在我們的系統(tǒng)中實(shí)現(xiàn)，來自外部系統(tǒng)的用戶余額更新不受我們系統(tǒng)的控制，有可能造成非

法數(shù)據(jù)被更新至數(shù)據(jù)庫。因此我們?cè)谧鲭娮由虅?wù)的時(shí)候，一定要小心的注意這項(xiàng)存在的問題，采用比

較合理的邏輯驗(yàn)證，避免數(shù)據(jù)執(zhí)行錯(cuò)誤。

　也可以在使用Session的load()或是lock()時(shí)指定鎖定模式以進(jìn)行鎖定。

　如果數(shù)據(jù)庫不支持所指定的鎖定模式，Hibernate會(huì)選擇一個(gè)合適的鎖定替換，而不是丟出一個(gè)例外 ?

from:?http://blog.csdn.net/it_man/article/details/1464038

總結(jié)

以上是生活随笔為你收集整理的hiernate的锁机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。