Hibernate樂觀鎖（OptimisticLocking）和悲觀鎖（pessimistic Locking)機制

Hibernate支持兩種鎖機制： 
即一般所說的「悲觀鎖（Pessimistic Locking）」和 「樂觀鎖（OptimisticLocking）」。 

悲觀鎖的實現，每每依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，不然，即便在本系統中實現了加鎖機制，也沒法保證外部系統不會修改數據）。 

Hibernate的加鎖模式有： 
Ø LockMode.NONE ： 無鎖機制。 
Ø LockMode.WRITE ：Hibernate在Insert和Update記錄的時候會自動 
獲取。 
Ø LockMode.READ ： Hibernate在讀取記錄的時候會自動獲取。 
以上這三種鎖機制通常由Hibernate內部使用，如Hibernate爲了保證Update 
過程當中對象不會被外界修改，會在save方法實現中自動爲目標對象加上WRITE鎖。 
Ø LockMode.UPGRADE ：利用數據庫的for update子句加鎖。 
Ø LockMode. UPGRADE_NOWAIT ：Oracle的特定實現，利用Oracle的for update nowait子句實現加鎖。 

 Hibernate的悲觀鎖，也是基於數據庫的鎖機制實現。 下面的代碼實現了對查詢記錄的加鎖：

1   String hqlStr  =   " from TUser as user where user.name=’Erica’ " ; 
2  Query query  =  session.createQuery(hqlStr); 
3  query.setLockMode( " user " ,LockMode.UPGRADE);  // 加鎖  
4   List userList  =  query.list(); // 執行查詢，

獲取數據 query.setLockMode 對查詢語句中特定別名所對應的記錄進行加鎖（咱們爲 TUser類指定了一個別名「user」），這裏也就是對返回的全部user記錄進行加鎖。 觀察運行期Hibernate生成的SQL語句： 

1   select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex from t_user tuser0_ where (tuser0_.name = ’Erica’ )  for  update

 這裏Hibernate經過使用數據庫的for update子句實現了悲觀鎖機制。 

上面這兩種鎖機制是咱們在應用層較爲經常使用的，加鎖通常經過如下方法實現： 
Criteria.setLockMode 
Query.setLockMode 
Session.lock 
注意，只有在查詢開始以前（也就是Hiberate 生成SQL 以前）設定加鎖，纔會 真正經過數據庫的鎖機制進行加鎖處理，不然，數據已經經過不包含for update 子句的Select SQL加載進來，所謂數據庫加鎖也就無從談起。

樂觀鎖，大可能是基於數據版本（Version）記錄機制實現。何謂數據版本？即爲數據增長一個版本標識，在基於數據庫表的版本解決方案中，通常是經過爲數據庫表增長一個「version」字段來實現。讀取出數據時，將此版本號一同讀出，以後更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，若是提交的數據版本號大於數據庫表當前版本號，則予以更新，不然認爲是過時數據。 

1． 首先爲TUser的class描述符添加optimistic-lock屬性：

 < hibernate - mapping >  
 < class  
name = " org.hibernate.sample.TUser "  
table = " t_user "  
dynamic - update = " true "  
dynamic - insert = " true "  
optimistic - lock = " version "  
 >  
…… 
 </ class >  
 </ hibernate - mapping >  

 

 添加一個Version屬性描述符 
代碼內容

 1   < hibernate - mapping >   
 2   < class   
 3  name = " org.hibernate.sample.TUser "   
 4  table = " t_user "   
 5  dynamic - update = " true "   
 6  dynamic - insert = " true "   
 7  optimistic - lock = " version "   
 8   >   
 9   < id  
10  name = " id "   
11  column = " id "   
12  type = " java.lang.Integer "   
13   >   
14   < generator  class = " native " >   
15   </ generator >   
16   </ id >   
17   < version  
18  column = " version "   
19  name = " version "   
20  type = " java.lang.Integer "   
21   />   
22  ……  
23   </ class >   
24   </ hibernate - mapping >   
25 

 

 

注意version 節點必須出如今ID 節點以後。
 這裏咱們聲明瞭一個version屬性，用於存放用戶的版本信息，保存在TUser表的 version字段中。 此時若是咱們嘗試編寫一段代碼，更新TUser表中記錄數據，如： 
代碼內容

1   Criteria criteria  =  session.createCriteria(TUser. class );  
2  criteria.add(Expression.eq( " name " , " Erica " ));  
3  List userList  =  criteria.list();  
4  TUser user  = (TUser)userList.get( 0 );  
5  Transaction tx  =  session.beginTransaction();  
6  user.setUserType( 1 );  // 更新UserType字段   
7   tx.commit();  
8 

 

每次對TUser進行更新的時候，咱們能夠發現，數據庫中的version都在遞增。 而若是咱們嘗試在tx.commit 以前，啓動另一個Session，對名爲Erica 的用 戶進行操做，以模擬併發更新時的情形： 
代碼內容

 1   Session session =  getSession();  
 2  Criteria criteria  =  session.createCriteria(TUser. class );  
 3  criteria.add(Expression.eq( " name " , " Erica " ));  
 4  Session session2  =  getSession();  
 5  Criteria criteria2  =  session2.createCriteria(TUser. class );  
 6  criteria2.add(Expression.eq( " name " , " Erica " ));  
 7  List userList  =  criteria.list();  
 8  List userList2  =  criteria2.list();TUser user  = (TUser)userList.get( 0 );  
 9  TUser user2  = (TUser)userList2.get( 0 );  
10  Transaction tx  =  session.beginTransaction();  
11  Transaction tx2  =  session2.beginTransaction();  
12  user2.setUserType( 99 );  
13  tx2.commit();  
14  user.setUserType( 1 );  
15  tx.commit();  
16 

執行以上代碼，代碼將在tx.commit()處拋出StaleObjectStateException異 常，並指出版本檢查失敗，當前事務正在試圖提交一個過時數據。經過捕捉這個異常，我 們就能夠在樂觀鎖校驗失敗時進行相應處理。 

悲觀鎖與樂觀鎖的比較: 
悲觀鎖大多數狀況下依靠數據庫的鎖機制實現，以保證操做最大程度的獨佔性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷每每沒法承受; 
相對悲觀鎖而言，樂觀鎖機制採起了更加寬鬆的加鎖機制。樂觀鎖機制每每基於系統中的數據存儲邏輯，所以也具有必定的侷限性，如在上例中，因爲樂觀鎖機制是在咱們的系統中實現，來自外部系統的更新操做不受咱們系統的控制，所以可能會形成髒數據被更新到數據庫中。在 
系統設計階段，咱們應該充分考慮到這些狀況出現的可能性，並進行相應調整（如將樂觀鎖策略在數據庫存儲過程當中實現，對外只開放基於此存儲過程的數據更新途徑，而不是將數據庫表直接對外公開）。 
Hibernate 在其數據訪問引擎中內置了樂觀鎖實現。若是不用考慮外部系統對數據庫的更新操做，利用Hibernate提供的透明化樂觀鎖實現，將大大提高咱們的生產力。 
Hibernate中能夠經過class描述符的optimistic-lock屬性結合version描述符指定。 
optimistic-lock屬性有以下可選取值： 
Ø none 
無樂觀鎖 
Ø version 
經過版本機制實現樂觀鎖 
Ø dirty 
經過檢查發生變更過的屬性實現樂觀鎖 
Ø all 
經過檢查全部屬性實現樂觀鎖 
其中經過version實現的樂觀鎖機制是Hibernate官方推薦的樂觀鎖實現，同時也是Hibernate中，目前惟一在數據對象脫離Session發生修改的狀況下依然有效的鎖機制。所以，通常狀況下，咱們都選擇version方式做爲Hibernate樂觀鎖實現機制。