如下圖所示，一天結束後，某商場核算員1和核算員2均要對庫存中的奶粉數量重新進行統計。假設庫存中原有奶
粉數量為1000，一天核心算員1和核算員2所在分割槽的銷售量均為200，核算員1讀取資料並開始計算，此時核算員2也
讀取資料開始計算，核算員1統計完後提交資料，庫存量變為800。但是核算員2手中持有的基數還是原有庫存量
1000，這樣一來就對不上賬了。。。
類似這種情況，我們就需要通過一些機制來保證這些資料在某個操作過程中不會被外界修改，也就是所謂
的「鎖」，即給我們選定的目標資料上鎖，使其無法被其它程式修改。
hibernate 支援兩種鎖機制來保證資料訪問的排他性：
1. 悲觀鎖（pessimistic locking）；
2. 樂觀鎖（optimistic locking）；
悲觀鎖，假定當前事務操縱資料資源時,肯定還會有其它事務同時訪問該資料資源,為了避免當前事務的操作受到 幹
擾,先鎖定資源。
如上所述，悲觀鎖對於資料被外界修改保持極端保守態度，當執行一條查詢時就要將整個過程中把資料鎖住，只
要事務不釋放（提交/回滾），那麼其他任何使用者都不能檢視或修改。這一過程，通過在應用程式中顯示地為資料資
源加鎖和資料庫機制相結合實現的。
悲觀鎖實現
session.begintransaction();
inventory inv = (inventory)session.load(inventory.class, "1001", lockmode.upgrade);
inv.setquantity(inv.getquantity() - 200);
session.gettransaction().commit();
機制，以操作最大程度的獨占性。但隨著而來的就是資料庫效能的大量開銷，特別是對長事務而言，這樣的開銷系統
往往無法承受。
樂觀鎖，假定當前事務操縱資料資源時,不會有其它事務同時訪問該資料資源,因此完全依靠資料庫的隔離級別來
自動管理鎖的工作。
樂觀鎖其實不是鎖，它只是一種檢測衝突的手段。相對悲觀鎖而言，樂觀鎖機制採取了寬鬆的加鎖機制，大多是
基於資料版本記錄機制或時間戳機制來避免可能出現的併發問題的。
什麼是資料版本？
資料版本，即為資料增加乙個版本標識，在基於庫表的版本解決方案中，一般是通過為資料庫表增加version欄位
來實現。在讀取資料的時候將version讀取出來，在儲存資料的時候先判斷version的值是否小於資料庫中的version
值，如果小於不予更新，否則給予更新。需要注意的是，只有真實修改物件的屬性,才會version加1。
如下圖所示，為庫存記錄新增version標識，當核算員1提交資料後庫存標識version版本由0變為1，當核算員2再
次提交時，當前版本號0小於現有庫存版本號1，因此不能進行更新操作。
什麼是時間戳？
同理，即為記錄新增時間標識。用時間是否相同來判斷是否要進行資料庫操作。不再做詳細介紹。
樂觀鎖實現
首先需要在實體類中新增version欄位
public class inventory
戳同理。
相比較而言，不難看出樂觀鎖更被提倡。
hibernate樂觀鎖和悲觀鎖
談到悲觀鎖和樂觀鎖，就要談到資料庫的併發問題，資料庫的隔離級別越高併發性就越差 併發性 當前系統進行了序列化後，你讀取資料庫後，別人查詢不了，稱為併發性不好 具有排它性 我鎖住當前資料後，比人看不到此資料 悲觀鎖一般是由資料庫機制來做到的 悲觀鎖的實現 通常依賴於資料庫機制，在整修過程中將資料庫鎖定...
hibernate悲觀鎖 樂觀鎖
1.多個事務併發會出現的錯誤情況 1 dirty read髒讀 讀了其他事務沒有提交的資料 2 none repeatable read不可重複讀 在同乙個事務中讀兩次得到不同的結果 3 phantom read幻讀 在同乙個事務中讀兩次得到不同的結果 針對插入和刪除 為了解決事務併發出現的三個問題...
hibernate悲觀鎖和樂觀鎖
如果資料庫不加鎖，在多個使用者訪問的時候，有可能會造成不可重複讀的問題 如，兩個使用者進行更新，並且這兩個使用者都先後的拿到了表中的記錄的數值，a使用者更新比 b使用者先更新完，但 b使用者還是按照初始的值進行更新，這時候就會造成不可重複讀 此時可以通過hibernate的悲觀鎖機制，對 hiber...