丢失更新(Lost-Update)与两阶段锁(2PL)死锁成因作答合理性核验请求

问题1（丢失更新问题）核验 #

你的作答核心逻辑正确，存在两处表述偏差需要修正：

• 你提到“T2在t2时刻读取B的操作属于脏读”表述错误：脏读的定义是读取到其他事务未提交的修改数据，此时T1还未对B做任何修改，两个事务读取的都是B的初始已提交值，不属于脏读，这一步是丢失更新的典型前置场景：多个事务先后读取同一数据的公共已提交版本，各自计算后先后提交，后提交的修改直接覆盖先提交的修改。
• 你提到的“中间计算结果部分提交”表述不准确：T1、T2计算得到B=120的过程都在各自事务的私有上下文内完成，未写入公共存储，不存在部分提交的说法，直到t7、t11才是正式的写入提交操作，最终T2的提交结果覆盖了T1对B的修改，导致T1对B加60的操作完全丢失，最终B值为120，不符合预期的240。
  待补充的版本控制方案参考方向：可以使用*MVCC（多版本并发控制）*乐观锁机制，给每行数据增加版本号标识，事务提交修改前校验读取数据时的版本号和当前数据库内的版本号是否一致，不一致则回滚重试，即可避免更新被覆盖的问题。

问题2（*2PL（两阶段锁）*场景下死锁问题）核验 #

你的作答逻辑完全正确：
*2PL（两阶段锁）*的核心规则是事务执行分为两个阶段：加锁阶段只能申请加锁、不能释放任何锁，解锁阶段只能释放锁、不能申请任何新锁。你给出的时序完全满足死锁的四个必要条件：

• 互斥条件：A、B的锁同一时间只能被一个事务持有
• 持有并等待：T1持有A的锁等待B的锁，T2持有B的锁等待A的锁
• 不可剥夺：加锁阶段的事务不能被其他事务强行剥夺已经持有的锁
• 循环等待：两个事务的持锁、等锁关系形成环路
  最终两个事务陷入无限等待，死锁成立。

内容的提问来源于stack exchange，提问作者Joshua Tabi