本篇介紹easymybatis如配置樂觀鎖和邏輯刪除。
easymybatis提供的樂觀鎖使用方式跟jpa一樣，使用@version註解來實現。即：資料庫增加乙個int或long型別欄位version，然後實體類version欄位上加上@version註解即可。實現原理是根據mysql的行鎖機制(innodb下)，同一條記錄只能被一條sql執行，後面的sql排隊等待。這樣version改變後，等待中的sql還是老的version號，因此更新失敗。
@version
private long version;
假設資料庫表中有乙個欄位is_deleted型別為tinyint，0表示未刪除，1表示已刪除。
實體類對應**如下：
public class user
如果is_deleted型別為char(1)，f表示未刪除，t表示已刪除。
@logicdelete(notdeletevalue = "f", deletevalue = "t")
private string isdeleted;
假設1表示未刪除，2表示已刪除，@logicdelete的設定方法如下：@logicdelete(notdeletevalue = 「1」, deletevalue = 「2」)。如果每個實體類都要這樣設定的話會很麻煩，easymybatis提供了全域性配置
# 未刪除資料庫儲存的值，預設為0
mybatis.logic-not-delete-value=1 # 刪除後資料庫儲存的值，預設為1 mybatis.logic-delete-value=2
樂觀鎖和悲觀鎖
1 悲觀鎖，正如其名，它指的是對資料被外界 包括本系統當前的其他事務，以及來自外部系統的事務處理 修改持保守態度，因此，在整個資料處理過程中，將資料處於鎖定狀態。悲觀鎖的實現，往往依靠資料庫提供的鎖機制 也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無...
樂觀鎖和悲觀鎖
併發衝突 在多使用者的環境下，如果使用者同時修改同乙個文件，就會造成衝突。典型的衝突有兩種 1 丟失更新 乙個使用者的更新記錄覆蓋了另乙個人的更新。如 使用者一 讀 寫 使用者二 讀 寫 那麼使用者一就把使用者二的更新覆蓋了。2 髒讀 乙個使用者更新資料未完成時，另乙個使用者就讀取資訊。使用者一 讀...
樂觀鎖和悲觀鎖
為什麼需要鎖 併發控制 在多使用者環境中，在同一時間可能會有多個使用者更新相同的記錄，這會產生衝突。這就是著名的併發性問題。典型的衝突有 l 丟失更新 乙個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。例如 使用者a把值從6改為2，使用者b把值從2改為6，則使用者a丟失了他的更新。l 髒讀...