|
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: |
