请问，在TIDB 悲观锁模式下，锁信息在执行DML阶段就已经写入了tikv 的lock cf ，如果执行事务A的某个tidb server（作为事务client角色） 异常了，经过测试，这个事务A持有的锁是不会阻塞后续其它事务对这个A事务涉及到行一个修改，所以可以推断出，这个事务A持有的锁应该是被其它事务清理了，这个事务A也是被回滚了，所以是怎么判断出事务异常中断的，在Percolator 下，会记录进行事务提交的Client的存活状态，但是不知道TIDB这方面怎么实现的，谢谢
经过测试，这个事务A持有的锁是不会阻塞后续其它事务对这个A事务涉及到行一个修改，所以可以推断出，这个事务A持有的锁应该是被其它事务清理了。 这句话没看懂，麻烦帮忙解析下。 事务 A 中包含的行，其他事务都不包括吗？ 然后，其他事务清理了 事务 A 中持有的锁？
老师，您好
假设是这么一个情况，悲观锁模式下
事务A，begin;update t1 set xxx where id= 1 语句，但是不提交事务
然后执行事务A的tidb server 宕机了，
我在tidb server B 开启1个事务B，执行 update t1 set xxx where id= 1 ，
发现事务B是能够正常修改id=1这行数据的，所以事务A对 id=1加的锁，应该是被清理了，否则事务B不可能修改成功，但是事务A对 id=1加的锁 是怎么被清理的呢？或者是说是怎么判断执行A事务的TIDB server 是已经宕机的状态，在正常状态下，如果事务A不提交的话，id=1这行数据的锁在未达到ttl之前，锁应该是一直存在的
1 个赞
观摩学习中
异常宕机事务应该是默认回滚的，你可以测试一下。
是的，但是我不知道这里面的一个机制是什么样的原理
TiKV 中有一个等锁队列，来等锁和唤醒等。具体的参考文档 TiDB 悲观锁实现原理
这篇文章也是没有说清楚，等待一个异常中断事务所持有的锁的时候，这个异常中断事务锁持有的锁是怎么被清理的？
事务所在的 tidb-server 如果一直正常，这个事务是会一直持有这个锁，因为会不断续 heartbeat。如果 crash 了，没有续 heartbeat，等到超过 ttl 的时间（几秒），就可以清理锁了。下一个事务就可以使用了。
我也认为是这种方案比较合理的，请问下，有这么方面的资料或者介绍嘛
这个给你参考一下~
1 个赞
参考Percolator论文一段内容：
异常处理（异步清理锁）
若客户端在 Commit 一个事务时，出现了异常， Prepare 时产生的锁会被留下。为避免将新事务 hang 住，Percolator必须清理这些锁。
Percolator用 lazy 方式处理这些锁：当事务A在执行时，发现事务B造成的锁冲突，事务A将决定事务B是否失败，以及清理事务B的哪些锁。 对事务A而言，能准确地判断事务B是否成功是关键。Percolator为每个事务设计了一个元素 cell 作为事务是否成功的同步标准，该元素产生的 lock 即为 primary lock 。A和B事务都能确定事务B的 primary lock （因为这个 primary lock 被写入了B事务其它所有涉及元素的 lock 里面）。执行一个清理 clean up 或者提交 commit 操作需要修改该 primary lock ，由于这些修改是基于Bigtable去做，所以只有一个清理或提交会成功。注意：
- 在B提交
commit之前,它会先确保其primary lock被write record所替代（即往primary的write cf写提交数据，并删除对应的lock cf）。 - 在A清理B的锁之前，A必须检查B的
primary以确保B未被提交，如果B的primary存在，则B的锁可以被安全的清理掉。
当客户端在执行两阶段提交的 commit 阶段失败时，事务依旧会留下一个提交点 commit point (至少一条记录会被写入 write 中)，但可能会留下一些 lock 未被处理掉。一个事务能够从其 primary lock 中获取到执行情况：
- 如果
primary lock已被write所替代，也就是说该事务已被提交，事务需要roll forword,也就是对所有涉及到的、未完成提交的数据，用write记录替代标准的锁standard lock。 - 如果
primary lock存在，事务被roll back(因为我们总是最先提交primary,所以primary未被提交时，可以安全地执行回滚)
我理解tidb对于tikv也是类似于一个client,a的tidb宕机相当于client断开，对应kv上的锁释放
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。