TX锁是区别于行级锁的（实验）

1、会话A：                                                                 

     savepoint a；

     Update table_name   ......where id=1；

说明：

A先获得TM（RX），再得TX（X），最后在id=1的数据行（的锁位）上加上行级锁（RLS）。

2、会话B：  

      Update table_name   ......where id=1； 

      被阻塞着

说明：

        会话B的服务器进程查看id=1的数据行后，发现该数据行上已经加了行级锁（RLS）。于是，会话B的服务器进程可能试图做一些数据块的cleanout块清除操作，故查看表的事务表，发现事务A还在且未被commit，又根据事务A的XID，找到事务A的TX lock为X模式（X模式与任何锁模式不兼容的）。因此，会话B的服务器进程就会在TX resource的Enqueue Waiter Linked List上创建一个X  mode(exclusive) 的enqueue lock（为欲加在事务A上的TX锁）。这也就是会话B的update语句被阻塞的原因。                                                 

3、会话A：                                                                 

     rollback  to  a；

  说明：

         事务A上的rollback  to  a语句除去id=1的数据行上的行级锁，但是不会释放TX锁。

4、会话C：

      Update table_name   ......where id=1；

      更新一行

      而会话B 依然还是被阻塞着。

说明：
      只有当事务A释放TX lock时，事务A才会查看该TX resource的Enqueue Waiter Linked List并发现事务B还在那里等待，于是就会POST一个信息给事务B说 TX lock已经被我释放，隐含的意思就是row lock也已经被我释放，你可以继续工作了。如果没有这个机制，若事务B在DML过程中发现其所需要的数据行已经被其他进程锁定了，如果不依赖于内存中的TX LOCK，这意味着事务B需要定期去读取检查该数据行锁在的数据块以发现相应的ROW LOCK是否已经被释放了，可以想象如果在OLTP环境中这样去设计所造成的性能损失将是巨大的。但是现在由于这个机制，事务B不会定期去读取检查该数据行锁在的数据块以发现相应的ROW LOCK是否已经被释放了，而是等着事务A的通知。可是事务A此时还没有释放TX lock，因而事务A不会通知事务BTX lock已经被我释放了，你可以继续工作了。故而事务B还在一直阻塞着。

      会话C因为刚开始，所以它会先查看id=1的数据行是否已经加了行级锁（RLS），这里没有，于是就更新成功了。

   

                                                                   

总结：

        本实验的第四步里的两个结果说明了TX锁是区别于行级锁的。TX锁是属于lock机制，要消耗内存的；行级锁不是属于lock机制，不用消耗内存的，只是消耗数据行上的锁位空间。由本实验的第四步，同时可以看出，TX锁（TM也是）的设计（存在）部分是出于效率的考虑的。如例子里，当事务A释放TX lock时，事务A会查看该TX resource的Enqueue Waiter Linked List并发现事务B还在那里等待，于是就会POST一个信息给事务B说 TX lock已经被我释放，而不用事务B需要定期去读取检查该数据行锁在的数据块以发现相应的ROW LOCK是否已经被释放了。