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
public int getversion()
....
} 而在映像檔案中，我們使用
optimistic-lock
屬性設定
version
控制，屬性欄之後增加乙個
標籤，如下：
optimistic-lock="version">
....
設定好版本控制之後，在上例中如果
b 客戶試圖更新資料，將會引發
stableobjectstateexception
例外，我們可以捕捉這個例外，在處理中重新讀取資料庫中的資料，同時將
b客戶目前的資料與資料庫中的資料秀出來，讓
b客戶有機會比對不一致的資料，以決定要變更的部份，或者您可以設計程式自動讀取新的資料，並重複扣款業務流程，直到資料可以更新為止，這一切可以在背景執行，而不用讓您的客戶知道。
但是樂觀鎖也有不能解決的問題存在：上面已經提到過樂觀鎖機制的實現往往基於系統中的資料儲存邏輯，在我們的系統中實現，來自外部系統的使用者餘額更新不受我們系統的控制，有可能造成非法資料被更新至資料庫。因此我們在做電子商務的時候，一定要小心的注意這項存在的問題，採用比較合理的邏輯驗證，避免資料執行錯誤。
也可以在使用
session
的load()
或是lock()
時指定鎖定模式以進行鎖定。
如果資料庫不支援所指定的鎖定模式，
hibernate
會選擇乙個合適的鎖定替換，而不是丟出乙個例外。
Hibernate鎖機制（悲觀鎖，樂觀鎖）
鎖 locking 業務邏輯的實現過程中，往往需要保證資料訪問的排他性。如在金融系統的日終結算處理中，我們希望針對某個cut off時間點的資料進行處理，而不希望在結算進行過程中 可能是幾秒種，也可能是幾個小時 資料再發生變化。此時，我們就需要通過一些機制來保證這些資料在某個操作過程中不會被外界修改...
Hibernate步步為營 鎖機制詳解
上篇文章詳細討論了hql的各種查詢方法，在討論過程中寫了 示例，hql的查詢方法類似於sql，查詢的方法比較簡單，有sql基礎的開發人員在使用hql時就會變得相當的簡單。hibernate在運算元據庫的同時也提供了對資料庫操作的限制方法，這種方法被稱為鎖機制，hibernate提供的鎖分為兩種一種是...
python鎖機制 python的鎖機制
鎖 lock lock 指令鎖 是可用的最低階的同步指令。lock處於鎖定狀態時，不被特定的執行緒擁有。lock包含兩種狀態 鎖定和非鎖定，以及兩個基本的方法。可以認為lock有乙個鎖定池，當執行緒請求鎖定時，將執行緒至於池中，直到獲得鎖定後出池。池中的執行緒處於狀態圖中的同步阻塞狀態。構造方法 l...