[发明专利]数据库事务锁机制的死锁检测方法及装置

说明书

技术领域

本发明涉及数据库技术领域，尤其涉及一种数据库事务锁机制的死锁检测 方法及装置。

背景技术

事务(Transaction)是数据库管理系统(DBMS)提供的基本也是最重要的 功能之一，而事务功能的实现要依赖2个核心基础技术：锁机制和REDO/UNDO 日志功能。锁机制是事务实现的核心技术，它关系到事务功能能否实现，系统 的性能和吞吐量，以及系统的稳定性。

各种数据库管理系统所采用的锁机制的基本理论是一样的，但是实现方法 各有不同。目前主流的数据库管理系统，如Oracle，Sybase，MS SQL Server， MySQL(InnoDB)等，都实现自己的一整套锁机制，各有其优缺点。

死锁检测是锁机制的一个关键技术。尽管在某些特定场景中可以使用一些方 法避免和降低死锁发生，但是死锁有时还是难以避免，因此死锁检测成了锁机 制中不可或缺的一部分。死锁检测需要消耗不少计算资源，其效率的好坏对系 统整体性能有不小的影响。

例如，MS SQL Server 2008的死锁检测方法如下：当锁监视器对特定线程启 动死锁搜索时，会标识线程正在等待的资源。然后，锁监视器查找特定资源的 所有者，并递归地继续执行对那些线程的死锁搜索，直到找到一个循环。用这 种方式标识的循环形成一个死锁。这属于事后检测。

再例如，InnoDB的死锁检测也有类似的递归算法，即，事务T1(请求者线 程)要对某个对象obj(表或者记录)加锁，当需要等待时，首先创建一个锁对 象wait_lock，然后事先测试是否发生死锁。它调用一个自递归函数 lock_deadlock_recursive(T1，wait_lock)，表示判断在wait_lock之前的加锁者 (事务)是否等待T1。具体死锁检测算法如下：1)如果加在对象obj上的前一 个锁不存在，则没有死锁，退出。2)判断是否wait_lock需要等待前一个锁lock， 且lock的拥有者T2等于T1，若是，则表示已经发生死锁，退出。3)得到事务 T2正在等待的锁wait_lock2，递归调用lock_deadlock_recursive(T1， wait_lock2)。可见，InnoDB也是采用递归调用的方式来测试是否出现事务之间 的等待环。

MS SQL Server和InnoDB都是采用递归方式来检测死锁，特别是InnoDB， 采用双向链表来组织保护对象已授予的锁对象列表，以及事务拥有的锁对象列 表，死锁检测算法遍历这些链表来检测等待环的存在。这种方式检测效率较低， 而且一次检测最多只能检测出一个等待环，同时检测过程对正在进行的线程(事 务)有不小的妨碍。

综上所述，目前大部分数据库管理系统，不管是事先检测还是事后检测， 主要都是利用资源图(已分配资源图和请求资源图)来检测死锁。这种方法的 缺点是丢失了加解锁过程中产生的有助于死锁检测的信息，使得死锁检测时需 要重新计算这些信息，造成死锁检测繁琐及计算资源的浪费。

发明内容

鉴于上述的分析，本发明旨在提供一种数据库事务锁机制的死锁检测方 法及装置，用以解决现有技术中存在的死锁检测繁琐及计算资源浪费的问题。

本发明的目的主要是通过以下技术方案实现的：

本发明提供了一种数据库事务锁机制的死锁检测方法，预定义一个用于存 放线程间等待关系信息的邻接矩阵，则所述方法包括：

步骤A：加锁线程将加锁过程中生成的线程间等待关系信息记录在所述邻 接矩阵中；

步骤B：解锁线程在解锁过程中根据需要更新所述邻接矩阵中的相应等待关 系信息；所述步骤B具体包括：步骤B1：在相关线程进行解锁过程中，进行解锁 的线程称为解锁线程；解锁线程对于所述邻接矩阵中记录的要申请解锁线程正 在释放的这把锁的每个线程，判断它所要申请的锁类型是否与该解锁线程拥有 的锁类型相容，若不相容，执行步骤B2；若相容，则执行步骤B3；步骤B2： 保持等待关系信息不变；步骤B3：判断是否与至少一个其他线程拥有的锁类型 不相容，如果是，则进行锁等待关系迁移，更新所述邻接矩阵中的相应等待关 系信息，否则仅清除原来的线程间等待关系信息；