[发明专利]用于数据库管理系统的死锁处理方法和系统

说明书

技术领域

本发明涉及一种面向应用的数据库管理系统(DBMS)死锁处理机制，更具体地说，涉及当DBMS发生死锁时基于面向应用逻辑的牺牲选择规则来进行死锁处理的方法和系统。

背景技术

目前，在并行处理的数据库管理系统中还不可能绝对地避免死锁。已经提出了许多对死锁进行检测的解决方案，这些方案对于应用端的服务质量可能有着不同的影响。

在图1中示出了常用的DBMS基础架构的示意图。其中，连接管理单元11把来自应用端的请求接收到DBMS引擎1中，并检查这个请求是否有效。如果是的话，连接管理单元11把这个请求传送给SQL编译器12，SQL编译器12把这个请求解译成一个或多个任务，并调用安全管理单元13，以进行授权和权限检查。所形成的任务由任务管理单元14所管理，任务管理单元14通过相应的任务控制模块(TCB)来识别各个任务。在这个DBMS系统中还包括线程管理单元15，它负责工作线程的维护和调度。例如当要启动一个任务时，线程管理单元15通过任务调度器调用一个工作线程，并通过把对应于该任务的TCB分配给这个工作线程，从而将其映射到该任务。在DBMS引擎1之外运行有一个死锁处理器2，它以规律的间隔持续地监控各工作线程，以检查是否发生死锁，当发生死锁时采取相应的动作。

现有的死锁处理机制是在DBMS系统内实现的，如由DBMS根据请求占用资源的多少来选择将要舍弃的任务，或者随机地进行选择，将牺牲的请求回滚(roll back)，并告知该请求发生了死锁错误。在现有的死锁处理机制中，DBMS端与应用端之间缺乏足够的交互，DBMS在选择要牺牲的请求时不会考虑到应用端逻辑，而当发生死锁时应用端也难以参与到死锁处理中。

但由于目前的牺牲选择模式仅仅是在DBMS端实现的，对于应用端而言不可见，即应用端无法参与到死锁的检测和处理中，因此在实践中这种牺牲选择的结果往往并不是在应用端角度所希望的结果。例如，在实际应用中有可能会把重要性更高的VIP客户的请求作为牺牲而退回。

现有技术中有一种解决死锁问题的方案，其允许应用程序在请求中将其自身的优先级设定为0至9，一旦发生死锁，DBMS将选择优先级较低的请求将其回滚。这种方案不能适用于两个请求具有相同优先级的场合。例如，如果普通客户和VIP客户同时提交请求，这导致他们的请求被绑定了相同的优先级，但实际上从应用端的角度看，这两个客户的重要性可能并不相同，服务器端对此并不了解，因而这种已有方案只考虑到了数据库管理的方便性，但不能避免对于实际需求而言错误的牺牲选择。

发明内容

本发明提供一种面向应用的DBMS死锁处理机制，其中能够基于应用端的实际需要所动态、灵活地确定的牺牲选择规则来在死锁发生时选择请求，从而避免得到实际应用不希望的牺牲选择结果。根据本发明所设定的规则与实际的应用端属性有关，并基于该属性的值对需要牺牲的请求进行选择。

根据本发明的一个方面，提供了一种用于数据库管理系统的死锁处理方法。该方法包括：

当检测到来自应用端的请求导致数据库管理系统发生死锁时，获取应用端的属性值并调用与应用端的需求相关的规则；

将所述属性值作为参数代入到所述规则中，根据所述规则中规定的条件计算出各请求的重要性，从而确定要牺牲的请求；并

终止所述要牺牲的请求的执行。

根据本发明的另一个方面，还提供了一种用于数据库管理系统的死锁处理系统。该系统包括：

死锁处理器，用于持续监控数据库管理系统，以检测是否有来自应用端的请求导致数据库管理系统发生死锁；

规则引擎，用于获取应用端的属性值并调用与应用端的需求相关的规则，将所述属性值作为参数代入到所述规则中，根据所述规则中规定的条件计算出各请求的重要性，从而确定要牺牲的请求并将其作为结果返回给死锁处理器，

其中，所述死锁处理器当检测到死锁发生时启动所述规则引擎，并根据规则引擎返回的结果指示数据库管理系统确定要牺牲的请求的执行。

可选地，所述规则引擎包括用于存放所述规则的规则库，以及用于执行确定要牺牲的请求的操作的规则运算单元。

根据本发明的可选实施方式，所述规则既可以由了解实际应用需求的规则创建者人工生成，也可以通过具有规则创建能力的特定应用程序根据实际应用需求自动生成。当实际应用需求发生了改变时，所述规则也可以相应地动态调整。

根据本发明的一个实施例，数据库管理系统在终止了要牺牲的请求后，将该请求回滚，并告知相应的应用端发生了死锁错误。