前幾天看到GOING MM關(guān)于Hibernate Transaction 的描述,這里順便轉(zhuǎn)載一篇hiberntae中鎖機(jī)制的文章:

   悲觀鎖定 假定任何時(shí)刻存取數(shù)據(jù)時(shí)，都可能有另一個(gè)客戶也正在存取同一筆數(shù)據(jù)，因而對(duì)數(shù)據(jù)采取了數(shù)據(jù)庫層次的鎖定狀態(tài)，在鎖定的時(shí)間內(nèi)其它的客戶不能對(duì)資 料進(jìn)行存取，對(duì)于單機(jī)或小系統(tǒng)而言，這并不成問題，然而如果是在網(wǎng)絡(luò)上的系統(tǒng)，同時(shí)間會(huì)有許多聯(lián)機(jī)，如果每一次讀取數(shù)據(jù)都造成鎖定，其后繼的存取就必須等待，這將造成效能上的問題，造成后繼使用者的長(zhǎng)時(shí)間等待。
　樂觀鎖定（optimistic locking）則樂觀的認(rèn)為資料的存取很少發(fā)生同時(shí)存取的問題，因而不作數(shù)據(jù)庫層次上的鎖定，為了維護(hù)正確的數(shù)據(jù)，樂觀鎖定使用應(yīng)用程序上的邏輯實(shí)現(xiàn)版本控制的解決。
　例如若有兩個(gè)客戶端，A客戶先讀取了賬戶余額1000元，之后B客戶也讀取了賬戶余額1000元的數(shù)據(jù)，A客戶提取了500元，對(duì)數(shù)據(jù)庫作了變更，此時(shí) 數(shù)據(jù)庫中的余額為500元，B客戶也要提取300元，根據(jù)其所取得的資料，1000-300將為700余額，若此時(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í)行，而不用讓您的客戶知道。


  悲觀鎖定在多個(gè)客戶端可能讀取同一筆數(shù)據(jù)或同時(shí)更新一筆數(shù)據(jù)的情況下，必須要有訪問控制的手段，防止同一個(gè)數(shù)據(jù)被修改而造成混亂，最簡(jiǎn)單的手段就是對(duì)數(shù)據(jù)進(jìn)行鎖定，在自己進(jìn)行數(shù)據(jù)讀取或更新等動(dòng)作時(shí)，鎖定其它客戶端不能對(duì)同一筆數(shù)據(jù)進(jìn)行任何的動(dòng)作。
　悲觀鎖定（Pessimistic Locking）一如其名稱所示，悲觀的認(rèn)定每次資料存取時(shí)，其它的客戶端也會(huì)存取同一筆數(shù)據(jù)，因此對(duì)該筆數(shù)據(jù)進(jìn)行鎖定，直到自己操作完成后解除鎖定。
　悲觀鎖定通常透過系統(tǒng)或數(shù)據(jù)庫本身的功能來實(shí)現(xiàn)，依賴系統(tǒng)或數(shù)據(jù)庫本身提供的鎖定機(jī)制，Hibernate即是如此，我們可以利用Query或Criteria的setLockMode()方法來設(shè)定要鎖定的表或列（row）及其鎖定模式，鎖定模式有以下的幾個(gè)：

  • LockMode.WRITE：在insert或update時(shí)進(jìn)行鎖定，Hibernate會(huì)在save()方法時(shí)自動(dòng)獲得鎖定。
  • LockMode.UPGRADE：利用SELECT … FOR UPDATE進(jìn)行鎖定。
  • LockMode.UPGRADE_NOWAIT：利用SELECT … FOR UPDATE NOWAIT進(jìn)行鎖定，在Oracle環(huán)境下使用。
  • LockMode.READ：在讀取記錄時(shí)Hibernate會(huì)自動(dòng)獲得鎖定。
  • LockMode.NONE：沒有鎖定。

　也可以在使用Session的load()或是lock()時(shí)指定鎖定模式以進(jìn)行鎖定。
　如果數(shù)據(jù)庫不支持所指定的鎖定模式，Hibernate會(huì)選擇一個(gè)合適的鎖定替換，而不是丟出一個(gè)例外（Hibernate參考手冊(cè)10.6）。

  原文出處:http://blog.csdn.net/chho/archive/2005/01.aspx