在项目中,更删改的时候需要自己来控制锁吗?还是完全交给oracle来控制锁?

解决方案 »

  1.   

    由oracle自行控制就好了,但要记得及时提交、或 rollback 一个transaction。
      

  2.   

    除自己有特殊需要, 其它情况下还是交给Oracle控制
      

  3.   

    那如果交给orcale自行控制的话,如果我正在修改表中一条记录的时候,别的用户能不能查询出来呀,还有能不能对其进行操作呀?
      

  4.   

    没有commit的话,同一用户名查询是更变后的结果, 不同的用户名查询的结果没有改变.
      

  5.   

    没有commit时, 更改记录后别的用户不能查询出来. 但是同一用户名可以看到更改后的结果.
      

  6.   

    “没有commit时,更改记录后别的用户不能查询出来.但是同一用户名可以看到更改后的结果.”,这种说法是错误的。
    应该是: 没有commit时,当前会话(session)看到的是更改后的结果.其他别的会话(session),包括同一用户名建立的会话都看到的都是修改前的内容.
      

  7.   

    可以用 SELECT FOR UPDATE NOWAIT 的方式锁住相关记录。
    这样在你没有commit或rollback的情况下,其他会话如果想更删改这些记录,甚至执行SELECT FOR UPDATE NOWAIT 语句都会产生异常。这样就保证同一时刻只有一个会话处理这些记录。
    注意,使用 SELECT FOR UPDATE NOWAIT 不要忘记commit或rollback,不然记录一直被锁定直到会话结束。
      

  8.   

    其实锁的基本操作都明白,包括6楼对5楼的详解~
    我就怕出现死锁的问题,会话A和会话B同时更新某张表的不同行的数据,A准备更新1行到10行,B准备更新15行到5行(倒序),当A更新到第5行时候,B正好更新到6行,这时候第5行被会话A锁住了,B只能等A来COMMIT,第6行被会话B锁住了,A只能等B来COMMIT,这时候产生了死锁的现象,都等待对方COMMIT,但是因为双方还没更新完毕,所以一直没有COMMIT,死锁....不知道我的想法有错误没,谢谢大家的讨论!
      

  9.   

    看来楼主对ORACLE的行级锁应该还是有些了解的. 你在9楼所述是典型的死锁,不过不用担心. 因为其中后等待的SESSION会自动回滚, 以避免双方持续等待. 至于谁会被回滚就看双方语句执行的顺序了, 比如:A锁定5,B锁定6后, A先开始对6进行操作,此时A等待,然后B开始对5操作时,B会话的事务就会被回滚. 总之,先发生的等待有优先权. 同时因为B被回滚,A就可以停止等待并继续其事务.应用交给ORACLE数据库来管理锁是正确的,但开发人员应该了解ORACLE死锁的处理机制, 同时应该避免通过应用逻辑的优化,避免死锁的发生. 毕竟发生死锁时,其中一个事务是要被强制回滚的. 那意味着有用户要投诉了.
      

  10.   

    左上有个<帖子加分>的按钮,也许按一下,你就知道了。我初来,也没发过帖,没给过别人分.;-) 自己试试吧.