ORCAL的并发问题

zyg0 2013-12-08 08:17:32
现在有一个表 多终端进行 调用 当一个终端 调用时 先将 查询到的字段 中 状态更新成1 避免其他终端访问 然后再 返回自己更新成 1 的结果 。在单用户测试 是没有问题 但是 当多终端并发时候 其他终端的 更新 数据会影响到 本终端。
初步的想法 是 将 这些操作写在一个存储过程中 。(sql server 中的经验 因为 sql 内部存储过程是按照队列执行的)
但是不知道在orcale 中 是不是 也有酱紫的队列和对应的方法
...全文
372 12 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
zyg0 2013-12-27
  • 打赏
  • 举报
回复
谢谢回复 加锁不是我的特长 呵呵 问题都解决 了 用隔离级别解决了
iihero 2013-12-17
  • 打赏
  • 举报
回复
引用 10 楼 chncaesar 的回复:
明显是个悲观锁的问题。

select col from table for update;
--update statement
commit;
无论谁先读这条记录,马上加上一个排它锁,阻塞其他终端。完成事务后,释放锁。
使用适当的事务隔离级一样可以达到这个效果.
chncaesar 2013-12-14
  • 打赏
  • 举报
回复
明显是个悲观锁的问题。

select col from table for update;
--update statement
commit;
无论谁先读这条记录,马上加上一个排它锁,阻塞其他终端。完成事务后,释放锁。
babaerzi17 2013-12-09
  • 打赏
  • 举报
回复
串行化事物处理,可能会有效率问题。
  • 打赏
  • 举报
回复
oracle是按照是否可获得相应锁来判断自身是否可以操作数据的
shenlele088 2013-12-09
  • 打赏
  • 举报
回复
存储过程不是串行的。 可以使用悲观锁,或在程序中写个服务专门相应此表修改。
zyg0 2013-12-09
  • 打赏
  • 举报
回复
顶一下
请叫我-雷人 2013-12-09
  • 打赏
  • 举报
回复
有详细的文档教程吗?求学习
zyg0 2013-12-09
  • 打赏
  • 举报
回复
引用 7 楼 babaerzi17 的回复:
串行化事物处理,可能会有效率问题。
我只想知道能不能解决 问题 否则 从新用锁来规划 太麻烦
CT_LXL 2013-12-08
  • 打赏
  • 举报
回复
引用 2 楼 zyg0 的回复:
难道用 一个 可串行化调用事物就能解决
LZ厉害,不用问了,你比大家都更清楚
zyg0 2013-12-08
  • 打赏
  • 举报
回复
难道用 一个 可串行化调用事物就能解决
zyg0 2013-12-08
  • 打赏
  • 举报
回复
学习 可串行化(Serializable) 提供最高级别的事务隔离。 这个级别模拟串行的事务执行, 就好象事务将被一个接着一个那样串行的,而不是并行的执行。 不过,使用这个级别的应用必须准备在串行化失败的时候重新发动事务. 当一个事务处于可串行化级别, 一个 SELECT 查询只能看到在事务开始之前提交的数据而永远看不到未提交的 数据或事务执行中其他并行事务提交的修改。 (不过,SELECT 的确看得到同一次事务中 前面的更新的效果.即使事务还没有提交也一样.) 这个行为和读已提交级别是不太一样的,读已提交看到的是 该事务开始时的快照,而不是该事务内部当前查询开始时的快照. 如果一个正在执行一个 UPDATE 语句(或者 DELETE 或者 SELECT FOR UPDATE 的查询返回的目标行正在被另一个并行的未提交的事务更 新,那么第二个试图更新此行的事务将等待另一个事务的提交或者回卷。 如果发生了回卷,等待中的事务可以继续修改此行。如果发生一个并行的 事务的提交,一个可串行化的事务将回卷,并返回下面信息。 ERROR: Can't serialize access due to concurrent update 因为一个可串行化的事务在 可串行化事务开始之后不能更改被其他事务更改过的行。 当应用收到这样的错误信息时,它应该退出当前的事务然后从头开始重新 进行整个事务.第二次运行时,该事务看到的前一次提交的修改是该数据库 初始的样子中的一部分,所以把新版本的行作为新事务更新的起点不会有 逻辑冲突. 请注意只有更新事务才需要重试 --- 只读事务从来没有串行化冲突. 可串行化事务级别提供了严格的保证:每个事务都看到一个完全完整的数据库 的视图.不过,如果并行更新令数据库不能维持串行执行的样子,那么应用 必须准备重试事务,而且重做复杂的事务的开销可能是非常可观的.所以我们 只建议在更新查询中包含足够复杂的逻辑,在读已提交级别中可能导致错误 的结果的情况下才使用.

17,140

社区成员

发帖
与我相关
我的任务
社区描述
Oracle开发相关技术讨论
社区管理员
  • 开发
  • Lucifer三思而后行
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧