严格两阶段锁(Strict 2PL)下提交顺序≠可串行化顺序示例咨询
Strict 2PL下事务提交顺序与可串行化顺序不一致的示例
存在符合要求的场景。Strict 2PL的核心保证是调度满足冲突可串行化,且不会出现脏读脏写,但并没有要求事务提交顺序必须和所有等价的可串行化顺序保持一致。
最简无冲突场景示例
当多个事务没有冲突读写操作时,天然存在多个等价的可串行化顺序,很容易出现提交顺序和部分可串行化顺序不匹配的情况。
设定两个完全独立的事务:
- T1:仅对数据A执行写入操作
W(A) - T2:仅对数据B执行写入操作
W(B)
两个事务操作的数据集没有重叠,不存在任何读写、写读、写写冲突,符合Strict 2PL规则的调度流程如下:
- T1申请A的排他锁,获得后执行
W(A) - T2申请B的排他锁,获得后执行
W(B) - T2先完成所有后续操作,提交事务,释放B的排他锁
- T1完成后续操作后提交,释放A的排他锁
此时事务提交顺序为 T2 → T1,但该调度等价的可串行化顺序有两种:T1→T2 和 T2→T1,显然提交顺序和T1→T2的可串行化顺序并不相等。
有冲突操作场景的说明
如果你的预设场景要求事务之间必须存在冲突操作,那么Strict 2PL下不存在提交顺序和唯一可串行化顺序不一致的情况。核心原因是冲突操作要求前序事务必须先释放锁才能让后序事务执行冲突操作,而Strict 2PL要求所有排他锁必须在事务提交之后才能释放,因此冲突顺序和提交顺序完全绑定,唯一的可串行化顺序也和提交顺序一致。
内容的提问来源于stack exchange,提问作者Anji Mohanicei
相关产品推荐
相关产品推荐

