pessimistic locking 考慮
) 使用select for update(nowait)不像optimistic locking需要用戶額外的編碼實現簡單
) 在交互式應用中行鎖的時間可能較長如果用戶所住該紀錄後離開終端則其他用戶將無法更新該紀錄(但用戶可以查看該記錄oracle 寫並不阻塞讀)在有線(服務器可以知道客戶端的狀態)應用中應用保留著客戶端的session可以通過數據庫或者應用服務器設置session的idle time如果客戶端長時間占有資源且不做操作則斷掉該連結釋放鎖但在無線(服務器無法知道客戶端的狀態)應用中則無法設置idle time斷掉客戶端
) UI交互如果紀錄已經被其他用戶鎖住當前用戶在修改紀錄之前就會獲知可以選擇等待或者取消等待
optimistic locking策略
因為在更新數據前讀取數據的時候不鎖紀錄所以要在更新紀錄的時候驗證紀錄是否已經被修改過這需要額外的代碼和設計常用的方法包括)整合所有相關列驗證)使用timestamp時間戳驗證
整合所有相關列驗證
Time: Ian read SHERSAs salary record:
SQL> select * from emp where name= SHERSA ;
ID NAME SALARY
SHERSA
Time: HR read SHERSAs salary record:
SQL> select * from emp where name= SHERSA ;
ID NAME SALARY
SHERSA
Time: Ian update SHERSAs salary by increment
SQL> update emp set salary= where id= and name= SHERSA and salary=;
SQL> commit;
SQL> select * from emp where name=SHERSA;
ID NAME SALARY
SHERSA
Time: HR update SHERSAs salary
SQL SQL> update emp set salary=salary* where id= and name= SHERSA and salary=;
rows updated
顯示行被更新了表示紀錄被其他用戶有效修改(無效修改指其他用戶雖然修改過但數值沒有變)過可以通過程序判斷提示用戶其他用戶已經修改過請再次提交你的修改請求…
顯然這個方法需要所有的驗證列都在where語句中開發的時候不夠靈活
使用timestamp時間戳驗證
在每個表中增加一個timestamp字段更新時候驗證timestamp字段
SQL> Alter table emp add mofied current_timestamp default (current_timestamp) not null;
增加一個timestamp字段標記該紀錄改動的時間
SQL> create or replace trigger upd_modified_emp_tri
before update on emp for each row
begin
:newmodified:=current_timestamp;
end;
/
Trigger created
建立必要的觸發器
Time: Ian read SHERSAs salary record:
SQL> select * from emp where id=;
ID NAME SALARY MODIFIED
SHERSA DEC AM
Time: HR read SHERSAs salary record:
SQL> select * from emp where id=;
ID NAME SALARY MODIFIED
SHERSA DEC AM
Time: Ian update SHERSAs salary by increment
SQL> update emp set salary= where id= and modified=to_timestamp(DEC AM);
row updated
SQL> commit;
SQL> select * from emp where id=;
ID NAME SALARY MODIFIED
SHERSA DEC AM
Time: HR update SHERSAs salary
SQL> update emp set salary=salary* where id= and modified=to_timestamp(DEC AM);
rows updated
顯示行被更新了表示紀錄被其他用戶修改可以通過程序判斷提示用戶其他用戶已經修改過請再次提交你的修改請求…
與第一種方法相比where部分只需要增加額外的字段timestamp字段即可低於i的版本可以自定義驗證列
optimistic locking考慮
optimistic locking需要用戶額外的編碼和設計比pessimistic復雜
) 在交互式應用中行鎖的時間較短僅僅在更新紀錄的時候獲得讀記錄時候不獲得鎖用戶操作的時候離開終端則其他用戶仍然可以更新該紀錄在無線應用中通常使用optimistic locking
) UI交互如果紀錄已經被其他用戶修改用戶費了很多精力和時間去填寫表格點擊[提交]結果系統返回[更新行請重新填寫]然後系統重新load新紀錄的表格用戶之前輸入的改動都將不再記憶
Reference:
lost update _P_DISPLAYIDF_P_CRITERIA:
From:http://tw.wingwit.com/Article/program/Oracle/201311/18868.html