【发布时间】:2009-09-11 07:51:16
【问题描述】:
悲观并发使用的具体场景有哪些?
【问题讨论】:
标签: database concurrency locking
悲观并发使用的具体场景有哪些?
【问题讨论】:
标签: database concurrency locking
悲观并发可能应该用于并发编辑尝试频繁发生的情况,而不是例外情况。当用户被告知他们的编辑不会被保存时,乐观并发可能会给用户带来不和谐的结果,因此在正常情况下应该避免这种情况。
【讨论】:
“何时使用 pess.locking”到底是什么意思?
如果您要处理 DBMS 管理的数据,则别无选择。 DBMS 在每次更新时都使用它,句号,因为如果 DBMS 本身想要确保数据完整性,它也别无选择。
即使是基于 MVCC 的系统(例如 Oracle ?)也别无选择,只能使用 2 阶段锁定序列化活动以正确处理以下情况:
TX A 开始,TX B 开始; TX A 插入 ID 1 ; TX B 插入 ID 1 ; TX A 检查约束; TX B 检查约束; TX A 提交; TX B 提交。
如果允许 A/B 的约束检查忽略 B/A 插入相同 ID 的操作,数据库最终会违反 key。
应用程序控制的锁最好只有在您可以确定它们不会在预期用户输入一些输入时(或者当正在执行可能导致长时间延迟的任何活动时)它们不会处于挂起状态时才悲观)。但这是对相反问题“何时不使用它”的回答。
编辑
“何时使用它”的一个指示可能是在高争用情况下,您希望“快速失败”的事务“其次”。这可以确保您无法完成的事务不会占用太多资源,并且这些资源可用于更快地完成(因此也更快地释放锁)“先来”并获得锁的事务。但是,请务必意识到,您遇到死锁的几率也会增加,而且由于锁是由应用程序控制的,因此解决任何死锁都取决于您。
【讨论】:
是的,当您绝对不能让两个人同时更改同一记录时。银行这样做最多。
【讨论】: