pessimistic锁定对optimistic锁定(2)

    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