pessimistic锁定对optimistic锁定(2)
2024-07-21 02:34:20
供稿：网友
pessimistic locking 考虑 1） 使用select for update(nowait)不像optimistic locking需要用户额外的编码，实现简单。 2） 在交互式应用中，行锁的时间可能较长。假如用户所住该纪录后，离开终端，则其他用户将无法更新该纪录（但用户可以查看该记录，Oracle 写并不阻塞读）。在“有线“(服务器可以知道客户端的状态)应用中，应用保留着客户端的session，可以通过数据库或者应用服务器设置session的idle time,假如客户端长时间占有资源且不做操作，则断掉该连结，释放锁。但在“无线”（服务器无法知道客户端的状态）应用中，则无法设置idle time断掉客户端。 3） UI交互。假如纪录已经被其他用户锁住，当前用户在修改纪录之前就会获知，可以选择等待或者取消等待。 optimistic locking策略 因为在更新数据前，读取数据的时候不锁纪录，所以要在更新纪录的时候，验证纪录是否已经被修改过；这需要额外的代码和设计。常用的方法包括1)整合所有相关列验证2)使用timestamp时间戳验证。 整合所有相关列验证 Time1: Ian read SHERSA’s salary record:
SQL> select * from emp where name=' SHERSA ' ; ID NAME SALARY ---------- ------------------------- ---------- 8 SHERSA 3000
Time2: HR read SHERSA’s salary record:
SQL> select * from emp where name=' SHERSA ' ; ID NAME SALARY ---------- ------------------------- ---------- 8 SHERSA 3000
Time3: Ian update SHERSA’s salary by increment 500 SQL> update emp set salary=3500 where id=8 and name=' SHERSA ' and salary=3000; SQL> commit; SQL> select * from emp where name='SHERSA'; ID NAME SALARY ---------- ------------------------- ---------- 8 SHERSA 3500 Time4: HR update SHERSA’s salary SQL SQL> update emp set salary=salary*1.05 where id=8 and name=' SHERSA ' and salary=3000; 0 rows updated. 显示0行被更新了，表示纪录被其他用户有效修改（无效修改指其他用户虽然修改过，但数值没有变）过；可以通过程序判定，提示用户“其他用户已经修改过，请再次提交你的修改请求….”. 显然，这个方法需要所有的验证列都在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 2 before update on emp for each row
3 begin 4 :new.modified:=current_timestamp; 5 end; 6 / Trigger created. 建立必要的触发器 Time1: Ian read SHERSA’s salary record: SQL> select * from emp where id=14;
ID NAME SALARY MODIFIED ---------- -------------------- ---------- --------------------- 14 SHERSA 3000 15-DEC-05 06.34.19.126861 AM
Time2: HR read SHERSA’s salary record:
SQL> select * from emp where id=14;
ID NAME SALARY MODIFIED ---------- -------------------- ---------- --------------------- 14 SHERSA 3000 15-DEC-05 06.34.19.126861 AM
Time3: Ian update SHERSA’s salary by increment 500 SQL> update emp set salary=3500 where id=14 and modified=to_timestamp('15-DEC-05 06.34.19.126861 AM'); 1 row updated. SQL> commit; SQL> select * from emp where id=14;
ID NAME SALARY MODIFIED ---------- -------------------- ---------- --------------------- 14 SHERSA 3500 15-DEC-05 06.35.39.585907 AM
Time4: HR update SHERSA’s salary SQL> update emp set salary=salary*1.05 where id=14 and modified=to_timestamp('15-DEC-05 06.34.19.126861 AM'); 0 rows updated. 显示0行被更新了，表示纪录被其他用户修改；可以通过程序判定，提示用户“其他用户已经修改过，请再次提交你的修改请求….”. 与第一种方法相比，where部分只需要增加额外的字段timestamp字段即可。低于9i的版本可以自定义验证列。 optimistic locking考虑 optimistic locking需要用户额外的编码和设计，比pessimistic复杂。 2） 在交互式应用中，行锁的时间较短，仅仅在更新纪录的时候获得。读记录时候不获得锁，用户操作的时候离开终端，则其他用户仍然可以更新该纪录。在“无线”应用中，通常使用optimistic locking。 3） UI交互。假如纪录已经被其他用户修改，用户费了很多精力和时间去填写表格，点击[提交]，结果系统返回[更新0行，请重新填写]，然后系统重新load新纪录的表格，用户之前输入的改动都将不再记忆。 Reference:
/ArtImage/20060802/locking.pdf
lost update http://asktom.oracle.com/pls/ask/f?p=4950:8:14381454400784279997::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:30562552526857
