前言
enq: TX - row contention这个等待事件，是涉足database性能优化领域的DBA，首先接触的一个问题，因为它简单，很容易作出一个测试案例，直观地理解锁的申请及等待机制。
看起来再常见不过的一个等待，也会出现百思不得解的问题。老猫近半年内遇上三起表现得非常奇怪的锁问题。
第一个案例
一个网闸系统，用insert语句从内网迁移大量的数据到云数据库，不定期地被卡住。现象是应用卡住20秒后报出Socket read timed out错误，应用捕获到Exception以后，尝试rollback事务，还是报Socket read time out，数据库一直在等SQL*NET more data from client/SQL*NET message from client。遗留了大量行锁在数据库中。
第二个案例
一条清理数据的delete语句，由于运行速度比较慢，kill了应用端程序，重新启动应用以后，发现delete语句不是慢的问题，而是彻底堵在enq: TX - row contetion上了。奇怪的是blocking session的事务已经不存在了(v$transaction里找不到这个事务)。
第三个案例
某系统发现大量的死锁，应用重启后，发现这回不是死锁那么简单了，而是永远拿不到锁了，最长时间的锁等待长达2000秒以上，最后重启数据库解决。
这些问题都有共同特征，就是应用重启或者报错断开后，client没有机会发送commit/rollback，session所申请的lock也就永远没机会释放。我们的疑问是：client端断开了，Oracle不会回滚事务并释放enqueue锁吗？答案当然是会的。问题是，server知道client已经断开了吗？内部的机制是什么？
本期直播中，我们将详述行锁内部机制，分析server没有释放锁的原因，通过测试案例解答上述三真实，请大家积极参与互动，互动中，贡献优质问题的兄弟，老猫会有书法作品相送噢。
简单的TX锁问题里，藏着大学问，预约直播，与老猫一起抽抽丝剥茧挖一挖TX锁里蕴藏的宝藏！
更多实战分享请关注公众号：“中亦安图”和“中亦安图服务号”以及视频号：“小y-黄远邦-中亦”和“中亦安图”！也可以加小y微信，shadow-huang-bj，进微信群探讨技术。喜欢就转发吧，您的转发是我们持续分享的动力！
