系統中，涉及到單據或其他實體的編輯的時候，如果有兩個及以上針對同一個實體并發操作的時候，如果不進行控制，會出現數據沖突。 對于這個問題，我們給出了通用的commonLock解決方案。以下以幾個典型場景案例為示范，解釋了這種機制； ## 一、場景1 場景1描述： A用戶登陸系統,打開一個單據的修改或審核某個單據的界面，B用戶此時,不應該可以打開該單據的修改或審核某個單據的界面。 解決方案： A用戶進入修改或審核某個單據的界面的時候,同時鎖定該單據，記錄鎖定人、鎖定時間，當其B用戶點擊該單據，準備進入修改或者審核的時候，提示該單據已經有某某在某某時間鎖定了，拒絕該用戶進入。當A提交了修改或者審核的時候，釋放該鎖定信息。 ## 二、場景2 場景2描述： 當一個單據被審核后，不應該因為遺留界面，再次被修改。 解決方案： 進入修改的界面的時候，首先檢測單據的狀態不能是已審核過。 為了更穩妥起見，提交修改的界面的時候，再次檢測單據的狀態不能是已審核通過。 ## 三、場景3 場景3描述： 如果單據已經關聯了SN,則不允許修改,只能審核不通過,提交修改,重新審核 ## 四、場景4 場景4描述： 如果同一個人同時打開了同一張單據的審核和修改,則只能成功提交一個,另外一個失敗并提示 ## 五、場景5 場景5描述： 區分修改和審核界面,分別持有不同的鎖,加一個鎖類型,修改或者審核 設計一張新的鎖定表，包括如下字段： 鎖定人、鎖定時間、鎖定單據類型、鎖定單據id、 再加一張鎖定歷史表，當解除鎖定后，數據遷移到鎖定歷史表，備查。