CN108140028B

CN108140028B - 在具有分布式数据库系统的网络中提供数据库访问控制的方法和架构

Info

Publication number: CN108140028B
Application number: CN201680052634.9A
Authority: CN
Inventors: B·P·杜罗斯; S·A·雷维拉克
Original assignee: Ab Initio Technology LLC
Current assignee: Ab Initio Technology LLC
Priority date: 2015-07-10
Filing date: 2016-07-05
Publication date: 2022-04-29
Anticipated expiration: 2036-07-05
Also published as: EP3882767A1; AU2016292783A1; JP2018527653A; AU2016292786B2; AU2016292783B2; AU2016292786A1; JP2018522347A; EP3320452B1; EP3882767B1; JP6563111B2; EP3320452A1; WO2017011219A1; CN108027829B; KR102074087B1; US10671576B2; US20170011085A1; KR102136941B1; US20170011074A1; KR20180030118A; CA2991128C

Abstract

在分布式数据库系统(102,202)中管理数据库事务包括：在第一节点处维持事务的第一多个记录，其中各记录与事务相关联并且包括事务的开始时间和曾在事务的开始时间处于活动的最旧事务的开始时间；在第二节点处维持事务的第二多个记录，第二多个记录包括与第二节点相关联的已完成事务的记录，各记录包括事务开始时间和事务结束时间；在第二节点处接收来自第一节点的消息，其中该消息包括在分布式数据库系统中的最旧当前活动事务的事务开始时间处于活动的最旧事务的开始时间；以及从所述第二多个记录中去除事务结束时间发生在最旧事务的开始时间之前的已完成事务的任何记录。

Description

在具有分布式数据库系统的网络中提供数据库访问控制的方法和架构

相关申请的交叉引用

本申请要求2015年7月10日提交的美国申请序列号62/190,843的优先权。

背景技术

本说明书涉及用于向分布式数据库系统的网络提供数据库访问控制的方法和架构。

数据库是可以使用软件程序进行管理和查询的结构化的持久性数据集。事务数据库管理系统是使用数据库“事务”对数据库中的数据进行操作(例如，存储和操纵)的关系数据库系统。一般来说，数据库事务代表数据库管理系统对数据库所进行的工作(包括一个或多个操作的)单个单元。为了确保可靠地处理数据库事务，数据库事务必须是原子性的(即，事务，包括其一个或多个操作中的全部操作，必须完整地完成或者对任何事务都没有影响)、一致性的(即，事务必须将数据库从一个有效状态移动至另一有效状态)、隔离性的(即，并行执行的事务导致数据库中出现与串行执行事务的情况下将会导致的状态相同的状态)、以及持久性的(即，与系统崩溃、错误和其它问题无关地，提交的事务将保持提交)。数据库事务的这组性质有时被称为“ACID”。

发明内容

在另一方面中，通常，一种用于管理包括多个节点的分布式数据库系统中的潜在并行事务的方法，所述方法包括以下步骤：在所述多个节点中的第一节点处维持多个事务的记录，各事务在所述多个节点中的一个或多个节点上执行，各记录具有多个事务状态中的事务状态，所述多个事务的记录包括第一事务的记录和第二事务的记录，在所述多个节点中的第二节点处执行所述第一事务包括用于访问所述第二节点上所存储的第一数据元素的操作，以及在所述第二节点处执行所述第二事务包括用于访问所述第二节点上所存储的第一数据元素的操作；在所述第二节点处从所述第一节点接收包括所述多个事务中的在所述第二节点上执行并且在所述第二事务的发起时间具有第一事务状态的任何事务的事务列表，所述事务列表包括所述第一事务；至少部分基于所述事务列表来判断为所述第二事务的结果取决于所述第一事务的结果；以及基于所述判断来使所述第二事务的执行暂停，直到所述第一事务完成之后为止。。

方面可以包括以下特征中的一个或多个调整。

至少部分基于所述事务列表来判断为所述第二事务的结果取决于所述第一事务的结果包括：判断为所述第一事务的发起时间发生在所述第二事务的发起时间之前，并且所述第一事务的提交时间发生在所述第二事务的发起时间之前。

所述事务列表是在所述第二事务的发起时间在所述第二节点处接收到的。

所述事务列表中所包括的事务包含在所述第二节点上执行并且在所述第二事务的发起时间具有所述第一事务状态的事务。

所述事务列表针对所述事务列表中的各事务包括该事务的发起时间。

所述第一事务状态表示事务正准备完成。

所述第一事务写入所述第一数据元素并且所述第二事务读取所述第一数据元素，并且利用所述第二事务所读取的所述第一数据元素的版本取决于所述第一事务的结果。

所述第一事务的可能结果包括事务中止结果和事务提交结果。

所述方法还包括以下步骤：在所述第一事务完成之后继续所述第二事务的执行，包括在所述第一事务的结果是所述事务中止结果的情况下，读取所述第一数据元素的第一版本。

所述方法还包括以下步骤：在所述第一事务完成之后继续所述第二事务的执行，包括在所述第一事务的结果是所述事务提交结果的情况下，读取利用所述第一事务写入的所述第一数据元素的第二不同版本。

所述第一事务和所述第二事务其中之一或这两者访问所述多个节点中的第三节点上所存储的数据元素。

所述第一事务和所述第二事务这两者尝试写入所述第一数据元素，并且所述第二事务处于所述第一事务状态。

至少部分基于所述事务列表来判断为所述第二事务的结果取决于所述第一事务的结果包括：判断为所述第二事务的发起时间发生在所述第一事务的发起时间之后且发生在所述第一事务的提交时间之前。

所述第一事务计划在所述第二事务之前提交写入，并且所述第二事务是否中止取决于所述第一事务得到事务中止结果还是事务提交结果。

所述方法还包括以下步骤：在所述第一事务完成之后继续所述第二事务的执行，包括在所述第一事务的结果是所述事务中止结果的情况下，写入所述第一数据元素的第一值。

所述方法还包括以下步骤：在所述第一事务完成之后继续所述第二事务的执行，包括在所述第一事务的结果是所述事务提交结果的情况下，中止所述第二事务。

在另一方面，通常，一种计算机可读介质，用于以非暂时性的形式存储软件，所述软件用于管理包括多个节点的分布式数据库系统中的潜在并行事务，所述软件包括用于使计算系统进行以下操作的指令：在所述多个节点中的第一节点处维持多个事务的记录，各事务在所述多个节点中的一个或多个节点上执行，各记录具有多个事务状态中的事务状态，所述多个事务的记录包括第一事务的记录和第二事务的记录，在所述多个节点中的第二节点处执行所述第一事务包括用于访问所述第二节点上所存储的第一数据元素的操作，以及在所述第二节点处执行所述第二事务包括用于访问所述第二节点上所存储的第一数据元素的操作；在所述第二节点处从所述第一节点接收包括所述多个事务中的在所述第二节点上执行并且在所述第二事务的发起时间具有第一事务状态的任何事务的事务列表，所述事务列表包括所述第一事务；至少部分基于所述事务列表来判断为所述第二事务的结果取决于所述第一事务的结果；以及基于所述判断来使所述第二事务的执行暂停，直到所述第一事务完成之后为止。

在另一方面，通常，一种用于管理潜在并行事务的设备，所述设备包括：多个节点，其配置在分布式数据库系统中，各节点包括至少一个处理器；以及通信介质，用于连接所述多个节点的端口以在所述多个节点之间发送和接收信息，其中，所述多个节点中的第一节点被配置为维持多个事务的记录，各事务在所述多个节点中的一个或多个节点上执行，各记录具有多个事务状态中的事务状态，所述多个事务的记录包括第一事务的记录和第二事务的记录，在所述多个节点中的第二节点处执行所述第一事务包括用于访问所述第二节点上所存储的第一数据元素的操作，以及在所述第二节点处执行所述第二事务包括用于访问所述第二节点上所存储的第一数据元素的操作，所述第二节点被配置为从所述第一节点接收包括所述多个事务中的在所述第二节点上执行并且在所述第二事务的发起时间具有第一事务状态的任何事务的事务列表，所述事务列表包括所述第一事务，所述第二节点被配置为至少部分基于所述事务列表来判断为所述第二事务的结果取决于所述第一事务的结果，以及所述第二节点被配置为基于所述判断来使所述第二事务的执行暂停，直到所述第一事务完成之后为止。

在方面中，通常，一种用于管理包括多个节点的分布式数据库系统中的数据库事务的方法，所述方法包括以下步骤：在所述多个节点中的第一节点处维持所述分布式数据库系统中的事务的第一多个记录，所述第一多个记录中的各记录与事务相关联并且包括该事务的开始时间和曾在该事务的开始时间处于活动的最旧事务的开始时间，所述第一多个记录的其中一个记录是所述分布式数据库系统中的最旧当前活动事务的记录；在所述多个节点中的第二节点处维持事务的第二多个记录，所述第二多个记录包括与所述第二节点相关联的已完成事务的记录，所述第二多个记录中的各记录包括事务开始时间和事务结束时间；在所述第二节点处接收来自所述第一节点的消息，其中来自所述第一节点的消息包括曾在所述分布式数据库系统中的所述最旧当前活动事务的事务开始时间处于活动的最旧事务的开始时间；以及从所述第二多个记录中去除事务结束时间发生在所述最旧事务的开始时间之前的已完成事务的任何记录。

方面可以包括以下特征中的一个或多个特征。

所述方法还包括：从所述第二节点发送针对来自所述第一节点的所述消息的请求。

所述方法还包括：在所述第二节点处接收来自所述第一节点的包括第三多个记录的消息，其中所述第三多个记录包括所述分布式数据库系统中的活动事务的记录，所述第三多个记录中的各记录包括事务开始时间；以及针对所述第二多个记录中的已完成事务的各记录，基于所述第三多个记录来判断是否去除该记录。

基于所述第三多个记录来判断是否去除该记录包括：将所述第三多个记录中的活动事务的记录的事务开始时间与从已完成事务的记录的事务开始时间开始直到已完成事务的记录的事务结束时间结束为止的时间间隔进行比较。

基于所述第三多个记录来判断是否去除该记录包括：在所述第三多个记录中的活动事务的记录的事务开始时间均未处于从已完成事务的记录的事务开始时间开始直到已完成事务的记录的事务结束时间结束为止的时间间隔内的情况下，将该已完成事务的记录从所述第二多个记录中去除。

基于所述第三多个记录来判断是否去除该记录包括：在所述第三多个记录中的活动事务的记录与从已完成事务的记录的事务开始时间开始直到已完成事务的记录的事务结束时间结束为止的时间间隔内的事务开始时间相关联的情况下，将该已完成事务的记录保存在所述第二多个记录中。

基于所述第三多个记录来判断是否去除该记录是在从所述第二多个记录中去除事务结束时间发生在所述最旧事务的开始时间之前的已完成事务的任何记录之后发生的。

所述方法还包括：在所述第二节点处接收用于访问与所述第二节点相关联的数据元素的第一事务；在所述第二节点处维持包括所述第二节点处的活动事务的记录的第三多个记录；以及基于所述第二多个记录和所述第三多个记录中的一种或两种记录来判断是否允许所述第一事务访问所述数据元素的多个版本中的数据元素的版本。

基于所述第二多个记录和所述第三多个记录中的一种或两种记录来判断是否允许所述第一事务访问所述数据元素的所述版本包括：判断与所述数据元素的所述版本相关联的第二事务的记录是否包括在所述第三多个记录中，并且在与所述数据元素的所述版本相关联的第二事务的记录包括在所述第三多个记录的情况下，判断为允许所述第一事务访问该数据元素；在所述第二事务的记录没有包括在所述第三多个记录中的情况下，判断所述第二事务的记录是否包括在所述第二多个记录中，并且在所述第二事务的记录包括在所述第二多个记录中的情况下，将所述第一事务的开始时间与所述第二事务的结束时间进行比较以判断是否允许所述第一事务访问该数据元素；以及在所述第二事务的记录不包括在所述第二多个记录或所述第三多个记录中的情况下，判断为允许所述第一事务访问该数据元素。

在所述第二事务的事务结束时间发生在所述第一事务的事务开始时间之前的情况下、并且在所述第二多个记录中不存在第三事务的记录的情况下，允许所述第一事务读取所述数据元素的所述版本，其中所述第三事务写入了所述数据元素的第二版本，并且所述第三事务的事务结束时间发生在所述第二事务的事务结束时间之后且发生在所述第一事务的事务开始时间之前。

在利用所述第一事务写入了所述数据元素的所述版本的情况下，允许所述第一事务读取所述数据元素的该版本。

在所述第二事务的事务开始时间发生在所述第一事务的事务开始时间之后的情况下，不允许所述第一事务读取所述数据元素的所述版本。

所述第二多个记录中的已完成事务的记录是基于记录的事务结束时间进行排序的。

从所述第二多个记录中去除事务结束时间发生在最旧活动事务的记录的事务开始时间之前的已完成事务的任何记录包括：从所述第二多个记录中的最近已完成事务的记录起，顺次迭代所述第二多个记录，直到识别出事务结束时间发生在最旧事务的记录的事务开始时间之前的已完成事务的记录为止；以及将所识别出的记录从所述第二多个记录中去除。

所述方法还包括：将事务结束时间发生在所识别出的记录的事务结束时间之前的已完成事务的任何记录从所述第二多个记录中去除。

在另一方面中，通常，一种计算机可读介质，用于以非暂时性的形式存储软件，所述软件用于管理包括多个节点的分布式数据库系统中的数据库事务，所述软件包括用于使计算系统执行以下操作的指令：在所述多个节点中的第一节点处维持所述分布式数据库系统中的事务的第一多个记录，所述第一多个记录中的各记录与事务相关联并且包括该事务的开始时间和曾在该事务的开始时间处于活动的最旧事务的开始时间，所述第一多个记录的其中一个记录是所述分布式数据库系统中的最旧当前活动事务的记录；在所述多个节点中的第二节点处维持事务的第二多个记录，所述第二多个记录包括与所述第二节点相关联的已完成事务的记录，所述第二多个记录中的各记录包括事务开始时间和事务结束时间；在所述第二节点处接收来自所述第一节点的消息，其中来自所述第一节点的消息包括曾在所述分布式数据库系统中的所述最旧当前活动事务的事务开始时间处于活动的最旧事务的开始时间；以及从所述第二多个记录中去除事务结束时间发生在所述最旧事务的开始时间之前的已完成事务的任何记录。

在另一方面中，通常，一种用于管理数据库事务的设备，所述设备包括：多个节点，其配置在分布式数据库系统中，各节点包括至少一个处理器；以及通信介质，用于连接所述多个节点的端口以在所述多个节点之间发送和接收信息，其中，所述多个节点中的第一节点被配置为维持所述分布式数据库系统中的事务的第一多个记录，所述第一多个记录中的各记录与事务相关联并且包括该事务的开始时间和曾在该事务的开始时间处于活动的最旧事务的开始时间，所述第一多个记录的其中一个记录是所述分布式数据库系统中的最旧当前活动事务的记录，所述多个节点中的第二节点被配置为维持事务的第二多个记录，所述第二多个记录包括与所述第二节点相关联的已完成事务的记录，所述第二多个记录中的各记录包括事务开始时间和事务结束时间，所述第二节点被配置为接收来自所述第一节点的消息，其中来自所述第一节点的消息包括曾在所述分布式数据库系统中的所述最旧当前活动事务的事务开始时间处于活动的最旧事务的开始时间，以及所述第二节点被配置为从所述第二多个记录中去除事务结束时间发生在所述最旧事务的开始时间之前的已完成事务的任何记录。

方面可以包括以下优点中的一个或多个优点。

配置在节点的网络中的分布式数据库系统可以允许每次处理在大的区域内发生的大量事务。例如，全球物流处理或信用卡处理可能涉及全球范围的少量时间内的大量事务。然而，特别是事务在大致相同的时间发生并且使用相同的数据的情况下，需要协调(或管理)这种大量事务以及应用于数据的关联操作，以获得事务的有意义结果。

这里所述的方面包括使用多版本并行控制实现的分布式数据库系统。通常，多版本并行控制使得特定数据元素的多个不同版本(即，唯一可识别且独立可修改的副本)保持在分布式数据库系统中。允许创建数据元素的新版本，这使得不需要在仅维持各数据元素的单个版本的情况下、为了防止向相同数据元素的并行(和潜在冲突的)访问而可能需要使用的特定封锁协议。还可以避免这种封锁所引起的较长等待时间，从而潜在地提高了系统整体的性能。

在分布式数据库系统中使用多版本并行控制的情况下，出现大量实际问题。例如，在多个并行事务访问相同数据元素的情况下，可能出现与允许这些事务中的哪些事务提交它们的作业有关的模糊性。一些传统的分布式数据库系统以导致事务的潜在浪费、过早和可能不正确的中止的方式解决这些模糊性。这里所述的方面被配置为以避免事务的潜在浪费、过早和可能不正确的中止的方式巧妙地解决这些模糊性。

在内存和存储容量有限的实际的分布式数据库系统中，保留数量过大的数据元素的先前版本可能会导致消耗不期望的内存/存储容量的量。这里所述的方面通过更精确地判断数据元素的哪些先前版本不再需要并且仅删除数据元素的这些不需要的先前版本，来巧妙地配置数据元素的不需要且过时的先前版本。用于其它目的的内存和/存储容量的可用性提高辅助了系统整体的性能。

在其它方面中，这里所述的分布式数据库系统在这种分布式多节点数据库系统上实现多版本并行控制和冲突解决。方面有利地将事务的记录(包括事务状态)本地地维持于事务正执行的数据库的节点处、以及维持于多节点数据库的领导节点处。事务的记录有利地允许对分布式数据库系统的网络内的并行事务进行细粒度的控制。

特定方面有利地使用多版本并行控制的快照隔离形式，从而允许数据元素的多个版本存在于数据库系统中，同时使得能够防止冲突。数据库系统中的事务以及数据的版本这两者有利地与时间戳或相似的事务标识符相关联，从而对事务之间的时间关系进行编码并且提供用于并行事务之间的冲突解决的机制。

维持数据元素的多个版本的一个优点是：可以容易地中止访问数据元素的事务，并且可以通过恢复到数据元素的先前版本来容易地撤消与该事务相关联的变化。

特定方面有利地利用两阶段提交过程来确保事务的原子性。

方面可以减轻分布式数据库系统中的竞争条件和/或模糊性的影响，由此避免事务的过早中止。

分布式数据库系统的节点维持先前完成或在节点上活动的事务的记录。使用事务的记录来识别分布式数据库系统中的竞争条件和/或模糊性。节点实现清除过程，以确保在节点处仅维持事务的相关记录并且在节点处不维持不相关记录。清除可以以高效方式进行，使得如以下更详细地所述，清除不会过度干扰系统中的其它有用处理。清除还可以促进用于防止访问可能具有数据元素的多个版本的相同数据的多个事务之间的冲突的后续处理。

根据以下的描述和权利要求书，本发明的其它特征和优点将变得明显。

附图说明

图1是包括分布式数据库系统的数据处理系统的框图。

图2是示出加入分布式数据库系统的包括写入操作的事务的框图。

图3是示出图2的事务在分布式数据库上执行操作的框图。

图4是示出图2的事务从领导节点接收准备消息的框图。

图5是示出图2的事务向领导节点发送OK消息的框图。

图6是示出图2的事务从领导节点接收提交消息的框图。

图7是示出加入分布式数据库系统的包括读取操作的事务的框图。

图8是示出图7的事务在分布式数据库上执行操作的框图。

图9是示出图7的事务从领导节点接收准备消息的框图。

图10是示出图7的事务向领导节点发送OK消息的框图。

图11是示出图7的事务从领导节点接收提交消息的框图。

图12是示出优化分布式数据库写入算法的步骤的流程图。

图13是示出分布式数据库系统中活动的第一事务和第二事务的框图。

图14是示出在图12的分布式数据库系统中第一事务从领导节点接收准备消息的框图。

图15是示出图14的第二事务从领导节点接收包括完成事务标识符的列表的准备消息、并且休眠直到第一事务完成为止的框图。

图16是示出图12的第一事务向领导节点发送not OK(不OK)消息的框图。

图17是示出图12的第一事务从领导节点接收中止消息并且图12的第二事务唤醒的框图。

图18是示出图12的第二事务向领导节点发送OK消息的框图。

图19是示出图12的第二事务从领导节点接收提交消息的框图。

图20是示出优化分布式数据库读取算法的步骤的流程图。

图21是示出在分布式数据库系统中第一事务从领导节点接收准备消息的框图。

图22是示出包括加入图19的分布式数据库系统的包括读取操作的第二事务的框图。

图23是示出图22的第二事务接收完成事务的列表、并且休眠直到可以在分布式数据库系统上安全地进行操作为止的框图。

图24是示出图19的第一事务向领导节点发送OK消息的框图。

图25是示出图19的第一事务从领导节点接收提交消息并且图22的第二事务唤醒的框图。

图26是示出图22的第二事务从领导节点接收准备消息的框图。

图27是示出图22的第二事务向领导节点发送OK消息的框图。

图28是示出图22的第二事务从领导节点接收提交消息的框图。

图29是示出乱序消息处理算法的步骤的流程图。

图30是示出在分布式数据库系统中活动的第一事务和第二事务的框图。

图31是示出图27的分布式数据库系统中的领导节点接收针对第一事务的END_TRANS消息的框图。

图32是示出图27的分布式数据库系统中的领导节点接收针对第二事务的END_TRANS消息的框图。

图33是示出图27的第二事务在第一事务接收到准备消息之前从领导节点包括完成事务标识符的列表的准备消息、并且休眠直到第一事务完成为止的框图。

图34是示出图27的第一事务接收准备消息的框图。

图35是示出图27的第一事务向领导节点发送OK消息的框图。

图36是示出图27的第一事务从领导节点接收提交消息的框图。

图37是示出图27的第二事务唤醒并且向领导节点发送Not OK消息的框图。

图38是示出图27的第二事务从领导节点接收中止消息的框图。

图39是示出在分布式数据库系统中第一节点向领导节点发送清除请求消息的框图。

图40是示出图39的领导节点将包括低水位线和活动事务的列表的消息发送回至第一节点、并且示出第一节点进行快速清除操作的框图。

图41是示出图39的领导节点将包括低水位线和活动事务的列表的消息发送回至第一节点、并且示出第一节点进行彻底清除操作的框图。

具体实施方式

图1示出包括分布式数据库系统102的数据处理系统100的示例。分布式数据库系统102经由通信网络106(例如，WAN、LAN或者多处理器系统中或芯片上的网络)与M个数据库客户端104进行通信。

1分布式数据库系统

分布式数据库系统102包括分配了数据库D的片段D_n的N个节点(或“分区”)108。在一些示例中，各节点108与在服务器计算系统上执行的服务器进程相对应。在一些示例中，多个节点108可以托管在单个处理器或计算机器上，或者节点108可以分布在多个处理器或计算机器上(例如，各节点108托管在自身的处理器上)。

各节点108包括存储有数据库D的片段的数据存储装置112和用于管理数据存储装置112上的数据库的片段的数据库管理器110。节点108的数据库管理器110还用作数据存储装置112上的数据库的片段与节点108外部的诸如客户端和其它节点108等的实体之间的接口。

在操作中，客户端104指定在数据库D上执行的一个或多个数据库事务。将客户端104所指定的事务经由通信网络106发送至节点108的数据库管理器110中的一个或多个数据库管理器110。在事务到达N个节点108的第n个数据库管理器110的情况下，第n个数据库管理器110使该事务在由第n个数据库管理器110管理的第n个数据存储装置112上所存储的数据库的片段上执行。

在一些示例中，在事务访问多个节点108上所存储的数据库的多个片段的情况下，第n个数据库管理器110将该事务转发至多个节点108的数据库管理器110。在其它示例中，事务源自于的客户端104将该事务发送至完成该事务所需的适当节点108。在另外的其它示例中，事务源自于的客户端104将该事务发送至领导节点，并且领导节点将该事务发送至完成该事务所需的适当节点108。

在适当节点108处接收到一个或多个事务的情况下，该一个或多个事务可以执行并访问数据库。与传统的集中式事务数据库的情况相同，一个或多个事务可能彼此冲突，从而导致一些事务成功地完成并且其它事务失败，此时这些失败的事务被迫撤消其改变并重试。

在一些示例中，上述的各数据库管理器110包括本地事务管理器114，其中该本地事务管理器114除了别的任务外还用于维持各事务过去具有的或者当前正在节点108上执行的记录等。在一些示例中，本地事务管理器114所管理的事务的各记录包括事务标识符(例如，事务的开始时间)、事务的提交标识符(例如，提交事务的时间)、以及事务的状态(例如，ACTIVE(活动)、PREPARING(准备中)、COMMITTED(已提交)或ABORTING(中止中))。尽管在图中没有明确示出，但在一些示例中，各数据库管理器110还包括：数据处理器，其负责管理由数据库管理器110管理的数据存储装置112上所存储的数据库的片段；应用处理器，用于处理需要向多于一个的节点108上的数据库片段的访问的请求；以及通信软件，用于与客户端104和其它节点108进行通信。

在一些示例中，将节点108其中之一(例如，图1中的节点2)指定为“领导”节点。领导节点包括全局事务管理器116，其中该全局事务管理器116负责向新的事务分配事务标识符，向事务分配提交标识符，并且协调分布式数据库系统102中的各节点108之间的提交操作。在一些示例中，全局事务管理器116还维持分布式数据库系统102中当前活动的所有事务的记录。在一些示例中，活动事务的各记录包括事务的事务标识符(例如，事务的开始时间)、事务的提交标识符(例如，提交事务的时间)、事务正工作的节点的列表、以及事务的状态(例如，ACTIVE、PREPARING、COMMITTED或ABORTING)。

1.1数据库事务

通常，在分布式数据库系统102中工作的各数据库事务与表示事务的生命期的时间间隔相关联。为了建立该时间间隔，当在数据库上工作的事务T开始时，向T分配事务标识符。事务标识符是标识分布式数据库系统102中的事务并且指定该事务的开始时间(即，时间间隔的开始)的全局独特编号。在一些示例中，为了实现这种标识符，将事务标识符生成为传达时间的概念的单调递增的数字序列。例如，关于具有事务标识符“10”的第一事务T[10]和具有事务标识符“20”的第二事务T[20]，由于T[10]的事务标识符在T[20]的事务标识符之前发生，因此可以辨别出T[10]在T[20]开始之前开始。

在事务准备提交时，向事务分配用于指定事务的结束时间(即，时间间隔的结束)的提交标识符。提交标识符源自于与事务标识符相同的数字序列，并且也传达时间的概念。

在一些示例中，记法T[a,b]用于表示生命期跨a～b的时间的事务。事务标识符a始终小于提交标识符b。可以将当前活动事务(即，没有提交的事务)表示为T[a,FUTURE]，其中设置b＝FUTURE暗示了事务将在FUTURE(将来)的某个未知时间结束。在一些示例中，使用简写表示T[a]来表示当前活动事务，其中暗示了b＝FUTURE。

与事务相关联的时间间隔可以提供与事务之间的关系有关的信息。例如，检查第一事务T[10,15]的时间间隔和第二事务T[16,20]的时间间隔提供了以下信息：这两个事务以第二事务在第一事务结束之后开始的方式串行地执行。检查第三事务T[10,20]的时间间隔和第四事务T[15,25]的时间间隔提供了以下信息：这两个事务并行地执行。注意，在本申请中，两个事务被视为在这两个事务的各生命期重叠时并行地执行。事务的生命期在与事务标识符相关联的时间开始，包括事务正积极地执行以进行有用工作的时间，包括验证阶段(例如，与事务相关联的JOIN(加入)、PREPARE(准备)和COMMIT(提交)消息/阶段)的时间，并且在与提交标识符相关联的时间结束，之后事务被视为完成。两个并行事务其中之一或这两者在生命期的任意部分中可能处于没有积极地执行以进行有用工作的暂停(或“休眠”)状态，并且这些事务仍被视为由于生命期重叠而并行地执行。

在一些示例中，在新的事务到达分布式数据库系统102时，该事务经历被称为“加入”的处理。为了加入，该事务请求向节点上的数据的访问，其中该节点不具有事务的先前记录。在接收到该请求时，该节点向领导节点上的全局事务管理器116发送“加入”消息，其中该消息包括节点的名称(例如，节点1)。在全局事务管理器116接收到该消息时，将该节点登记为事务中的参与者。

然后，全局事务管理器116发送针对节点108的具有事务的事务标识符、事务的“低水位线”和事务的“完成事务标识符”的列表的回复。一般而言，事务的低水位线是在事务开始时分布式数据库系统102中的最旧活动事务的事务标识符。完成事务标识符的列表是在事务开始时处于准备中的过程内的事务的列表。以下更详细地说明低水位线和完成事务标识符的列表。

1.2数据元素版本控制

在一些示例中，使用作为多版本并行控制(MVCC)的具体形式的快照隔离技术来实现数据库D。在这种数据库中，针对数据库中的数据元素中的一个或多个数据元素，可以存在多个版本。数据元素的各版本具有唯一标识符，使得可以将数据元素的不同版本彼此区分开。在一些示例中，针对数据元素的各版本，该版本的唯一标识符与将该版本写入到数据库的事务的事务标识符相对应。即，每次事务将数据元素的新版本写入到数据库时，将写入该新版本的事务的事务标识符分配为该新版本的标识符。例如，命名为x的数据元素可以具有包括利用事务T[25,30]、T[37,42]和T[53,59]分别写入的x[25]、x[37]和x[53]的多个版本。

1.3数据可见性

上述的版本控制技术可以由分布式数据库系统102的节点108使用，以确定允许事务访问数据元素的哪些版本并且识别操作冲突的事务。在识别出存在冲突操作的事务的情况下，这些事务其中之一可能被迫中止。为此，在一些示例中，在事务尝试访问一个或多个数据元素时，分布式数据库系统102的节点108遵守以下规则：

1)假定数据元素x(其中，x[m]是利用事务T[m]写入的x的版本)，在事务T[i]尝试读取x的情况下，T[i]可以读取在T[i]开始之前提交的x的最近版本。即，T[i]能够读取x[j](其中，j是小于i的最大事务标识符)，使得T[j]写入x，并且T[j]在T[i]开始之前提交。

2)假定数据元素x(其中，x[i]是利用事务T[i]写入的x的版本)，在不存在事务T[j]的情况下T[i]可以提交，使得T[j]写入x，T[j]与T[i]并行，并且T[j]首先提交。

通常，以上规则提供了并行事务之间的高度隔离。特别地，第一个规则防止了脏读(即，数据元素的未提交版本的读取)，并且第二个规则防止了数据的意外改写。这些规则都不需要阻塞或等待。

1.4两阶段提交过程

由于分布式数据库系统102的分布式性质，在经由通信网络106的消息的发送和接收之间存在固有的延迟，并且在节点108处接收并处理网络消息的顺序可能不同于发送这些网络消息的顺序。由于该固有的延迟，因此(从客户端的角度)确保原子性是复杂的操作。为了从客户端的角度确保原子性，分布式数据库系统102使用两阶段提交过程来协调分布式数据库系统102的节点108之间的提交操作。

在两阶段提交过程中，分布式数据库系统102上工作的事务可以处于ACTIVE状态、PREPARING(或PREPARED(已准备))状态、COMMITTING(提交中)(或COMMITTED)状态或ABORTING(或ABORTED(已中止))状态。在PREPARE阶段，参与事务的各节点进行验证过程以决定事务是否可以提交。如果所有的参与者都(以肯定方式)同意事务可以提交，则该事务提交。否则，该事务中止。

1.5分布式数据库写入

在图2～6中，例示出写入数据元素的新版本并且使用两阶段提交协议成功提交的事务的一个示例。参考图2，分布式数据库系统202的一部分包括第一节点108a、第二节点108b和第五节点108c。(注意，针对给定示例将节点标记为“第一”或“第二”等并不妨碍在其它示例中适当地改变这些标记)。将第二节点108b指定为分布式数据库系统202的领导节点。第一事务T[52,75]先前在第一节点108a上完成，这样使得将数据元素的版本x[52]218写入到第一节点108a上的第一数据库片段112a。将第一事务的第一本地记录220存储在第一节点108a的第一本地事务管理器114a中。

在客户端将开始事务消息(未示出)发送至全局事务管理器116时，在分布式数据库系统202处发起第二事务。全局事务管理器116创建第二事务的全局记录221：T[105,FUTURE]，并且向客户端回应Started T[105]消息(未示出)。然后，客户端在第一节点108a处发出针对事务T[105]的Write(x)命令，并且在第五节点108c处发出针对事务T[105]的一个或多个其它命令(未示出)。由于第二事务对于第一节点108a和第五节点108c而言是新的，因此第一节点108a和第五节点108c各自将针对第二事务的Join(T[105])消息发送至领导节点(即，第二节点108b)的全局事务管理器116。全局事务管理器116更新全局记录221以反映第一节点108a和第五节点108c加入了事务：T[105,FUTURE]:N₁N₅。全局记录221表示：具有事务标识符105的事务当前活动(即，全局记录221的提交标识符是FUTURE)，并且正在第一节点108a和第五节点108c上工作。参考图3，全局事务管理器116将针对T[105]的空的“完成事务标识符的列表”(即，以下更详细地所述的())发送回至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c。第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c各自创建第二事务的第二本地记录222：T[105,FUTURE]。第一节点108a继续执行Write(x)命令，这样使得将x的第二版本x[105]224写入到第一数据库片段112a。尽管在图中未示出，但第五节点108c也继续执行针对第二事务的命令。

参考图4，一旦第二事务的命令完成，客户端通过将结束事务消息(未示出)发送至全局事务管理器116来发起针对第二事务的提交序列，而这生成了第二事务的提交标识符(即，111)，并且更新第二事务的全局记录221以包括该提交标识符。全局事务管理器116还将第二事务的全局记录221标记为处于PREPARE状态(在图4中示出为星号(*))，这样得到全局记录221的更新版本：T[105,111]*:N₁N₅。全局事务管理器116将包括空的完成事务标识符的列表(即，())的Prepare(T[105,111])消息发送至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c。响应于从全局事务管理器116接收到Prepare(T[105,111])消息，第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c将第二事务的本地记录更新为T[105,111]，并且判断这两者是否准备提交第二事务。

参考图5，第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c这两者都向全局事务管理器116回应表示这两个节点108a、108c准备提交第二事务的OK(T[105])消息。参考图6，响应于从第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c接收到OK(T[105])消息，全局事务管理器116将Commit(T[105])消息发送至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c，从而使第二事务提交(包括提交x的新写入版本x[105])。

1.6分布式数据库读取

在图7～11中，例示出读取数据元素的版本并且使用两阶段提交协议来提交的事务的一个示例。参考图7，分布式数据库系统202的一部分包括第一节点108a、第二节点108b和第五节点108c。将第二节点108b指定为分布式数据库系统202的领导节点。第一事务T[52,75]先前在第一节点108a上完成，这样使得将数据元素x的版本x[52]1518写入到第一节点108上的第一数据库片段112a。将第一事务的第一本地记录1520存储在第一节点108a的第一本地事务管理器114a中。

在客户端将开始事务消息(未示出)发送至全局事务管理器116时，在分布式数据库系统202处发起第二事务。全局事务管理器创建第二事务的全局记录1521：T[80,FUTURE]，并且向客户端回应Started T[80]消息(未示出)。然后，客户端在第一节点108a处发出针对事务T[80]的Read(x)命令，并且在第五节点108c处发出针对事务T[80]的一个或多个其它命令(未示出)。由于第二事务对于第一节点108a和第五节点108c而言是新的，因此第一节点108a和第五节点108c各自将针对第二事务的Join(T[80])消息发送至领导节点(即，第二节点108b)的全局事务管理器116。全局事务管理器116更新第二事务的全局记录1521以反映第一节点108a和第五节点108c加入了事务：T[80,FUTURE]:N₁N₅。全局记录1521表示：具有事务标识符80的事务当前活动(即，全局记录1521的提交标识符是FUTURE)，并且正在第一节点108a和第五节点108c上工作。

参考图8，全局事务管理器116将针对T[80]的完成事务标识符的列表(即，在这种情况下为空的())发送回至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c。第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c各自创建第二事务的第二本地记录1622：T[80,FUTURE]。第一节点108a继续执行Read(x)命令，这样使得从第一数据库片段112a读取x[52]。尽管在图中未示出，但第五节点108c也继续执行针对第二事务的命令。

参考图9，一旦第二事务的命令完成，客户端通过将结束事务消息(未示出)发送至全局事务管理器116来发起针对第二事务的提交序列，而这生成了第二事务的提交标识符(即，85)，并且更新第二事务的全局记录1521以包括该提交标识符。全局事务管理器116还将第二事务的全局记录1521标记为处于PREPARE状态(在图9中示出为星号(*))，这样得到全局记录1521的更新版本：T[80,85]*:N₁N₅。全局事务管理器116将包括空的完成事务标识符的列表(即，())的Prepare(T[80,85])消息发送至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c。响应于从全局事务管理器116接收到Prepare(T[80,85])消息，第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c各自将第二事务的第二本地记录1622更新为T[80,85]，并且判断这两者是否准备提交第二事务。

参考图10，第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c这两者都向全局事务管理器116回应表示这两个节点108a、108c准备提交第二事务的OK(T[80]))消息。参考图11，响应于从第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c接收到OK(T[80])消息，全局事务管理器116将Commit(T[80])消息发送至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c，从而使第二事务提交。

1.7优化分布式数据库操作

在上述的示例性分布式数据库事务中，在两阶段提交过程中不会遇到任何复杂情况的情况下，在分布式数据库上执行读取操作和写入操作这两者。然而，在一些示例中，在一个或多个事务处于PREPARE阶段的情况下，可能发生模糊性，并且模糊性导致分布式数据库系统102中的低效操作。

如以下更详细地所述，使用维持在节点108上执行的各事务的记录的本地事务管理器114来减轻这些模糊性。本地事务管理器所存储的事务的各记录包括事务的生命期T[i,k](其中，对于仍活动的事务，k＝FUTURE)。本地事务管理器所维持的记录可用来解决由于模糊性而产生的某些冲突。

1.7.1优化分布式数据库写入

在一些示例中，在第一事务和第二事务都写入了数据元素的不同版本并且都处于PREPARE阶段(其中，第二事务的事务标识符大于第一事务的事务标识符并且小于第一事务的提交标识符)的情况下，模糊性可能会导致发生低效。特别地，由于并不知晓第一事务将提交还是中止，因此第二事务无法知晓第二事务是否应当中止写入操作。这可能导致第二事务过早中止。

参考图12，为了避免发生这种情形，使用优化数据库写入算法1200。在优化数据库写入算法1200的第一步骤1202中，在领导节点的全局事务管理器处接收到针对包括数据库写入操作(可能还包括其它操作)的事务的开始事务消息。在第二步骤1204中，将参与数据库写入操作的数据库系统的节点的本地事务管理器将Join()消息发送至全局事务管理器。在第三步骤1206中，事务在参与该事务的节点处所存储的数据元素上执行。在第四步骤1208中，在事务的执行完成时，在全局事务管理器处接收到结束事务消息。在第五步骤1210中，全局事务管理器将包括完成事务的列表的Prepare()消息发送至参与节点的本地事务管理器。

在第六步骤1212中，参与节点的本地事务管理器将完成事务的列表与这些本地事务管理器当前管理的事务的记录进行比较，以判断在事务进入准备状态之前、在与该事务相同的数据元素上工作的任何其它事务是否进入PREPARE状态。如果存在这种先前事务，则该算法进入第七步骤1214，其中在该第七步骤1214中，本地事务管理器使事务休眠(即，由本地事务管理器置于SUSPENDED(暂停)状态)，直到先前事务完成为止。这样暂停事务使与是否中止事务有关的决定延迟，直到先前事务的结果已知为止。

在不存在这种先前事务的情况下、或者在事务唤醒时，该算法进入第八步骤1216，其中在该第八步骤1216中，本地事务管理器判断事务是否可以提交。

如果可以提交事务，则该算法进入第九步骤1218，其中在该第九步骤1218中，参与节点的所有本地事务管理器将OK()消息发送至全局事务管理器。在后续的第十步骤1220中，全局事务管理器将Commit()消息发送至参与节点的本地事务管理器。最后，在第十一步骤1222中，在参与节点处提交事务的变化。

如果不能提交事务，则该算法进入第十二步骤1224，其中在该第十二步骤1224中，参与节点的本地事务管理器中的一个或多个本地事务管理器将NotOK()消息发送至全局事务管理器。在后续的第十三步骤1226中，全局事务管理器将Abort()消息发送至参与节点。最后，在第十四步骤1228中，在参与节点处回滚事务的变化。

以下示例例示图12的算法中的步骤1210～1228的应用。参考图13，分布式数据库系统202的一部分包括第一节点108a、第二节点108b和第五节点108c。将第二节点108b指定为分布式数据库系统202的领导节点。第一事务T[100,FUTURE]将数据元素x的第一新版本x[100]626写入了第一节点108a上的第一数据库片段112a，并且在第五节点108c上进行了一个或多个其它操作(未示出)。第二事务T[105,FUTURE]将数据元素x的第二新版本x[105]224写入了第一节点108a上的第一数据库片段112a，并且在第五节点108c上进行了一个或多个其它操作(未示出)。全局事务管理器116包括第一事务的第一全局记录721：T[100,FUTURE]:N₁N₅。第一全局记录721表示：第一事务具有事务标识符100并且当前在第一节点108a和第五节点108c上活动。全局事务管理器116还包括第二事务的第二全局记录726：T[105,FUTURE]:N₁N₅。第二全局记录726表示：第二事务具有事务标识符105并且当前在第一节点108a和第五节点108c上活动。第一事务的第一本地记录T[100,FUTURE]720和第二事务的第二本地记录T[105,FUTURE]722这两者都存储在第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c中。

参考图14，一旦第一事务的命令完成，客户端通过将结束事务消息(未示出)发送至全局事务管理器116来发起针对第二个第一事务的提交序列，而这生成第一事务的提交标识符(即，110)并且更新第一事务的第一全局记录721以包括该提交标识符。全局事务管理器116还将第一事务的第一全局记录721标记为处于PREPARE状态(在图14中示出为星号(*))，这样得到第一全局记录721的更新版本：T[100,110]*:N₁N₅。全局事务管理器116将包括空的完成事务标识符的列表(即，())的Prepare(T[100,110])消息发送至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c。响应于从全局事务管理器116接收到Prepare(T[100,110])消息，第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c各自将第一事务的第一本地记录720更新为T[100,110]，并且开始判断这两者是否准备提交第一事务。

参考图15，一旦第二事务的命令完成，客户端通过将结束事务消息(未示出)发送至全局事务管理器116来发起针对第二事务的提交序列，而这生成第二事务的提交标识符(即，111)并且更新第二事务的第二全局记录726以包括该提交标识符。全局事务管理器116还将第二事务的第二全局记录726标记为处于PREPARE状态(在图15中示出为星号(*))，这样得到第二全局记录726的更新版本：T[105,111]*:N₁N₅。全局事务管理器116将Prepare(T[105,111])消息发送至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c。连同Prepare(T[105,111])一起，全局事务管理器116发送“完成事务标识符”的列表。在该示例中，由于T[100]是完成事务(即，在利用全局事务管理器116发送Prepare(T[105,111])消息之前，T[100]处于PREPARE状态)，因此完成事务标识符的列表包括T[100]。

响应于从全局事务管理器116接收到Prepare(T[105,111])消息，第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c各自将第二事务的第二本地记录722更新为T[105,111]，并且开始判断这两者是否准备提交第二事务。

在图15所示的某瞬时，分布式数据库系统102需要判断第二事务是否安全地提交。在进行该操作的一个简单方法中，分布式数据库系统102可以将第一事务的提交标识符与第二事务的提交标识符进行比较，以判断哪个事务具有最早的提交标识符。具有两个提交标识符中的较迟的提交标识符的事务中止。在图15的示例中，第二事务将使用该简单方法中止。然而，第一事务处于PREPARE状态并且尚未提交。实际上，第一事务可能中止。如果第一事务中止，则上述的简单方法将具有这两个事务都中止的低效且不期望的结果。

为了避免这种低效且不期望的结果，使用利用完成事务标识符的列表的另一方法来判断第二事务是否可以安全地提交。特别地，在第二事务处于PREPARE阶段的情况下，咨询完成事务标识符的列表，以判断是否存在正访问与第二事务相同的数据元素并且具有比第二事务的事务标识符小的事务标识符的任何完成事务。在这种情况下，(完成事务标识符的列表中所包括的)第一事务处于PREPARING状态，正访问与第二事务相同的数据元素(即，x)，并且具有比第二事务的事务标识符(即，105)小的事务标识符(即，100)。由于本地事务管理器114无法知晓第一事务将成功地提交还是中止，因此本地事务管理器114使第二事务暂停，直到第一事务提交或中止为止。

参考图16，第一节点108a的数据库管理器110a将表示第一事务可以提交的OK(T[100])消息发送至全局事务管理器116。然而，第五节点108c将表示第一事务不能提交的Not OK(T[100])消息发送至全局事务管理器116。参考图17，作为从第五节点108c接收到Not OK(T[100])消息的结果，全局事务管理器116通过去除第一全局记录721并且将Abort(T[100])消息发送至第一节点108a和第五节点108c，来中止第一事务。

在从全局事务管理器116接收到Abort(T[100])消息时，第一节点108a将数据元素x的x[100]版本从数据片段112a中去除，并且将第一本地记录720从本地事务管理器114a中去除。同样，第五节点108c将第一本地记录720从本地事务管理器114c中去除。在第一事务中止的情况下，第二事务唤醒。

参考图18，在唤醒时，第一节点108a的数据库管理器110a将表示第二事务准备提交的OK(T[105])消息发送至全局事务管理器116。第五节点108c也将表示第二事务准备提交的OK(T[105])消息发送至全局事务管理器116。

参考图19，在从第一节点108a和第五节点108c接收到OK(T[105])消息的情况下，全局事务管理器116判断为第二事务正进行工作的所有节点指示了第二事务准备提交。全局事务管理器116将第二全局记录726标记成不再准备，并且将Commit(T[105])消息发送至第一节点108a和第五节点108c，从而使第二事务提交(包括在第一节点108a的数据库片段112a上使x的x[105]版本提交)。

1.7.2优化分布式数据库读取

在一些示例中，在第一事务写入了数据元素的新版本且处于PREPARE阶段、并且具有用于读取数据元素的操作且事务标识符比第一事务的事务标识符大且比第一事务的提交标识符大的第二事务处于活动的情况下，可能会发生可能导致系统的低效操作的模糊性。特别地，由于并不知晓第一事务将提交还是中止，因此第二事务无法知晓是读取数据元素的新版本还是数据元素的先前版本。

参考图20，为了避免发生这种情形，使用优化数据库读取算法1900。在优化数据库读取算法1900的第一步骤1902中，在领导节点的全局事务管理器处接收到针对包括数据库读取操作(可能还包括其它操作)的事务的开始事务消息。在第二步骤1904中，要参与数据库读取操作的数据库系统的节点的本地事务管理器将Join()消息发送至全局事务管理器。在第三步骤1906中，全局事务管理器将完成事务的列表发送至参与节点的本地事务管理器。

在第四步骤1908中，在读取数据元素之前，参与节点的本地事务管理器将完成事务的列表与这些本地事务管理器当前管理的事务进行比较，以判断完成事务的列表中的任何其它事务是否处于PREPARE状态并且写入发起事务之前的数据元素的版本。如果这种完成事务确实存在，则该算法进入第五步骤1910，其中在该第五步骤1910中，本地事务管理器使事务暂停，直到完成事务完成为止。使事务暂停延迟了与利用事务读取数据元素的哪个版本有关的决定。在不存在这种完成事务的情况下、或者在事务唤醒时，该算法进入第六步骤1912，其中在该第六步骤1912中，针对在事务的发起之前最近提交的数据元素的版本执行读取操作。

在第七步骤1913中，在全局事务管理器处接收到结束事务消息。在第八步骤1915中，全局事务管理器将Prepare()消息发送至参与节点的本地事务管理器。

在第九步骤1914中，本地事务管理器判断是否可以提交事务。如果可以提交事务，则该算法进入第十步骤1916，其中在该第十步骤1916中，所有参与节点的本地事务管理器将OK()消息发送至全局事务管理器。在后续的第十一步骤1918中，全局事务管理器将Commit()消息发送至参与节点的本地事务管理器。最后，在第十二步骤1920中，在参与节点处提交事务的变化。

如果不能提交事务，则该算法进入第十三步骤1922，其中在该第十三步骤1922中，参与节点中的一个或多个参与节点的本地事务管理器将NotOK()消息发送至全局事务管理器。在后续的第四步骤1924中，全局事务管理器将Abort()消息发送至参与节点的本地事务管理器。最后，在第十五步骤1926中，在参与节点处回滚事务的变化。

例如，参考图21，分布式数据库系统202的一部分包括第一节点108a、第二节点108b和第五节点108c。将第二节点108b指定为分布式数据库系统202的领导节点。第一事务T[52,75]先前在第一节点108a上完成，这样使得将数据元素x的版本x[52]2018写入到第一节点108上的第一数据库片段112a。第二事务T[100,110]在第一节点108a和第二节点108b这两者上都是活动的，并且将数据元素x的版本x[100]2019写入到第一节点108a上的第一数据库片段112a。将第一事务的第一本地记录2020存储在第一节点108a的本地事务管理器114a中。将第二本地记录2022存储在第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c中。全局事务管理器116将针对第二事务的包括空的完成事务标识符的列表(即，())的Prepare(T[100,110])消息发送至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c。

参考图22，在客户端将开始事务消息(未示出)发送至全局事务管理器116时，在分布式数据库系统202处发起第三事务。全局事务管理器116创建第三事务的全局记录2127：T[111,FUTURE]，并且向客户端回应Started T[111]消息(未示出)。然后，客户端在第一节点108a处发出针对事务T[111]的Read(x)命令，并且在第五节点108c处发出针对事务T[111]的一个或多个其它命令(未示出)。由于第三事务对于第一节点108a和第五节点108c而言是新的，因此第一节点108a和第五节点108c各自将针对第三事务的Join(T[111])消息发送至领导节点(即，第二节点108b)的全局事务管理器116。全局事务管理器116更新第三事务的第二全局记录2127以反映出第一节点108a和第五节点108c加入了事务：T[111,FUTURE]:N₁N₅。第二全局记录2127表示：具有事务标识符111的事务当前活动(即，第二全局记录2127的提交标识符是FUTURE)，并且正在第一节点108a和第五节点108c上工作。

参考图23，全局事务管理器116将完成事务标识符的列表发送回至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c。在该示例中，由于T[100]是完成事务(即，T[100]处于PREPARE状态)，因此完成事务标识符的列表包括T[100]。第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c各自创建第三事务的第三本地记录2225：T[111,FUTURE]。

在图23所示的时间点处，在第三事务之前，T[111]尝试读取x。第一节点108a的本地事务管理器114a通过咨询完成事务的列表来判断第三事务读取x是否安全，以判断是否存在正访问与第三事务相同的数据元素并且具有比第三事务的事务标识符小的事务标识符的任何完成事务。如果存在任何这种完成事务，则第三事务读取x不安全。在这种情况下，第二事务处于PREPARING状态，正访问与第三事务相同的数据元素(即，x)，并且具有比第三事务的事务标识符(即，111)小的事务标识符(即，100)。

由于处于PREPARING的第二事务，因此第三事务T[111]不能判断应当读取x[52]还是x[100]。即，在第二事务T[100,110]处于准备阶段的情况下，并不知晓第二事务将COMMIT还是ABORT。如果第二事务中止，则第三事务应当读取x[52]。否则，如果第二事务提交，则第三事务应当读取x[100]。

然而，已知第二事务不久将作出决定(即，COMMIT或ABORT)，因而第一节点108a的本地事务管理器114a暂停第三事务，直到第二事务完成(即，已提交)为止。

参考图24，第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c都向全局事务管理器116回应表示这两个节点108a、108c都准备提交第二事务的OK(T[100])消息。参考图25，响应于从第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c接收到OK(T[100])消息，全局事务管理器116将Commit(T[100])消息发送至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c，从而使第二事务提交。

在第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c接收到Commit(T[100])消息的情况下，本地事务管理器114a、114c知晓第二事务已成功地提交(并且并未中止)。本地事务管理器114a、114c唤醒第三事务，然后第三事务从第一数据库片段112a读取x[100]。参考图26，一旦第三事务的操作完成，全局事务管理器116生成第三事务的提交标识符(即，115)，并且更新第三事务的第二全局记录2127以包括该提交标识符。全局事务管理器116还将第三事务的第二全局记录2127标记为处于PREPARE状态(在图26中示出为星号(*))，这样得到第二全局记录2127的更新版本：T[111,115]*:N₁N₅。

全局事务管理器116将包括空的完成事务标识符的列表(即，())的Prepare(T[111,115])消息发送至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c。响应于从全局事务管理器116接收到Prepare(T[111,115])消息，第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c将各自的第三事务的第三本地记录2225更新为T[111,115]，并且判断这两者是否准备提交第三事务。

参考图27，第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c都向全局事务管理器116回应表示这两个节点108a、108c都准备提交第三事务的OK(T[111])消息。参考图28，响应于从第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c接收到OK(T[111])消息，全局事务管理器116将Commit(T[111])消息发送至第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c，从而使第三事务提交。

1.8乱序消息处理

在一些示例中，可以将针对两个或更多个事务的诸如PREPARE消息等的消息按第一顺序从全局事务管理器116发送至分布式数据库系统102中的节点108，但按与第一顺序不同的第二顺序到达节点108中的一个或多个节点108的本地事务管理器114。如果按在本地事务管理器114处接收到PREPARE消息的顺序而不是按从全局事务管理器116发送PREPARE消息的顺序来处理这些PREPARE消息，则可能发生诸如通过误中止应当提交的事务而违反第一提交者获胜规则(即，对于写入数据元素的两个并行事务，要提交的第一事务获胜并且另一事务必须中止)等的副作用。这种副作用可能引起系统的低效且潜在不正确的操作。

参考图29，为了防止发生这种情形，使用乱序消息处理算法2700。在第一步骤2702中，在参与第一事务的节点的本地事务管理器处接收到包括完成事务的列表的Prepare()消息。在第二步骤2704中，本地事务管理器将第一事务与完成事务的列表以及事务管理器所管理的事务进行比较，以判断完成事务的列表中是否存在正向与第一事务相同的数据元素进行写入但在参与节点处尚未处于PREPARE状态的任何事务。

如果识别出任何这种事务，则针对第一事务的Prepare()消息是以乱序方式接收到的，并且该算法进入第三步骤2706，其中在该第三步骤2706中，本地事务管理器使第一事务暂停，直到所识别出的事务完成为止。使第一事务暂停直到所识别出的事务完成为止，这样重新建立了适当的消息排序，使得没有违反第一提交者获胜规则。

在针对第一事务的Prepare()消息不是以乱序方式接收到的情况下、或者在第一事务唤醒时，该算法进入第四步骤2708，其中在该第四步骤2708中，本地事务管理器判断是否可以提交第一事务。如果可以提交第一事务，则该算法进入第五步骤2710，其中在该第五步骤2710中，所有参与节点的本地事务管理器将OK()消息发送至全局事务管理器。在后续的第六步骤2712中，全局事务管理器将Commit()消息发送至参与节点的本地事务管理器。最后，在第七步骤2714中，在参与节点处提交第一事务的变化。

如果不能提交第一事务，则该算法进入第八步骤2716，其中在该第八步骤2716中，参与节点中的一个或多个参与节点的本地事务管理器将NotOK()消息发送至全局事务管理器。在后续的第九步骤2718中，全局事务管理器将Abort()消息发送至参与节点的本地事务管理器。最后，在第十步骤2720中，在参与节点处回滚第一事务的变化。

例如，参考图30，分布式数据库系统202的一部分包括第一节点108a、第二节点108b和第五节点108c。将第二节点108b指定为分布式数据库系统202的领导节点。第一事务T[100,FUTURE]将数据元素x的第一新版本x[100]626写入到第一节点108a上的第一数据库片段112a，并且在第五节点108c上进行了一个或多个其它操作(未示出)。第二事务T[105,FUTURE]将数据元素x的第二新版本x[105]224写入到第一节点108a上的第一数据库片段112a，并且在第五节点108c上进行了一个或多个其它操作(未示出)。全局事务管理器116包括第一事务的第一全局记录721：T[100,FUTURE]:N₁N₅。第一全局记录721表示：第一事务具有事务标识符100，并且当前在第一节点108a和第五节点108c上是活动的。全局事务管理器116还包括第二事务的第二全局记录726：T[105,FUTURE]:N₁N₅。第二全局记录726表示：第二事务具有事务标识符105，并且当前在第一节点108a和第五节点108c上是活动的。第一事务的第一本地记录T[100,FUTURE]720和第二事务的第二本地记录T[105,FUTURE]722这两者都存储在第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c中。

参考图31，在全局事务管理器116(例如，从客户端104其中之一)接收到END_TRANS(T[100])消息的情况下，全局事务管理器116生成第一事务的提交标识符(即，110)，并且更新第一事务的第一全局记录721以包括该提交标识符。全局事务管理器116还将第一事务的第一全局记录721标记为处于PREPARE状态(在图31中示出为星号(*))，这样得到第一全局记录721的更新版本：T[100,110]*:N₁N₅。

参考图32，在全局事务管理器116(例如，从客户端104其中之一)接收到END_TRANS(T[105])消息的情况下，全局事务管理器116生成第二事务的提交标识符(即，111)，并且更新第二事务的第二全局记录726以包括该提交标识符。全局事务管理器116还将第二事务的第二全局记录726标记为处于PREPARE状态(在图32中示出为星号(*))，这样得到第二全局记录726的更新版本：T[105,111]*:N₁N₅。

参考图33，首先，全局事务管理器116将包括空的完成事务标识符的列表(即，())的Prepare(T[100,110])消息发送至本地事务管理器114a、114c。然后，全局事务管理器将后续的Prepare(T[105,111])消息连同包括T[100]的完成事务标识符的列表一起发送至本地事务管理器114a、114c。

在图33的示例中，Prepare(T[105,111])消息及其关联的完成事务标识符的列表在Prepare(T[100,110])消息之前到达本地事务管理器114a、114c。即，Prepare(...)消息是以乱序方式接收到的。如果按在本地事务管理器114a、114c处接收到Prepare(...)消息的顺序简单地处理这些Prepare(...)消息，则本地事务管理器114a、114c将判断为第二事务T[105,111]是第一提交者，从而使T[100]中止。当然，由于第二事务T[105,111]实际不是第一提交者，因此中止第一事务T[100]将是误操作。实际上，由于第一事务T[100,110]在第一全局记录721中具有比第二事务的提交标识符111小的提交标识符100，因此第一事务T[100,110]是第一提交者。

为了避免误中止第一事务，在该示例中，在接收到Prepare(T[105,111])消息时，本地事务管理器114a、114c检查完成事务标识符的列表，以判断任何事务是否写入了与第二事务T[105,111]相同的数据元素并且处于PREPARE状态。在这种情况下，由于第一事务T[100]包括在完成事务标识符的列表中(即，第一事务T[100]处于PREPARE状态)、并且写入了第二事务T[105,111]也写入的数据元素x的版本，因此第一事务T[100]满足这些条件。代替中止第一事务T[100]，本地事务管理器114a、114c暂停第二事务T[105,111]，直到已知第一事务T[100]的结果为止。

参考图34，在本地事务管理器114a、114c处接收到Prepare(T[105,111])消息之后的某点处，在本地事务管理器114a、114c处接收到Prepare(T[100,110])消息。响应于从全局事务管理器116接收到Prepare(T[100,110])消息，第一节点108a的本地事务管理器114a和第五节点108c的本地事务管理器114c各自将第一事务的第一本地记录720更新为T[100,110]，并且开始判断这两者是否准备提交第一事务。

参考图35，第一节点108a的数据库管理器110a将表示第一事务准备提交的OK(T[100])消息发送至全局事务管理器116。第五节点108c也将表示第一事务准备提交的OK(T[100])消息发送至全局事务管理器116。

参考图36，在从第一节点108a和第五节点108c接收到OK(T[100])消息的情况下，全局事务管理器116判断为第一事务正工作的所有节点都表示出第一事务准备提交。全局事务管理器116将第一全局记录721标记为不再准备，并且将Commit(T[100])消息发送至第一节点108a和第五节点108c，从而使第一事务提交(包括第一节点108a的数据库片段112a上使x的x[100]版本提交)。

参考图37，在第一事务提交的情况下，第二事务唤醒。在唤醒时，第一节点108a的数据库管理器110a将Not OK(T[105])消息发送至全局事务管理器116，其中该Not OK(T[105])消息表示由于第二事务违反第一提交者获胜规则，因此第二事务不能在第一节点108a上提交。第五节点108c的数据库管理器110c发送表示第二事务可以提交的OK(T[105])消息。

参考图38，作为从第一节点108a接收Not OK(T[105])消息的结果，全局事务管理器116通过去除第二全局记录726、并且将Abort(T[105])消息发送至第一节点108a和第五节点108c，来中止第二事务。

在从全局事务管理器116接收到Abort(T[105])消息时，第一节点108a将数据元素x的x[105]版本从数据片段112a中去除，并且将第二本地记录722从本地事务管理器114a中去除。同样地，第五节点108c将第二本地记录722从本地事务管理器114c中去除。

1.9本地事务管理器清除机制

如上所述，分布式数据库系统102中的各节点108的本地事务管理器114维持过去具有的或者在节点108上当前执行的各事务的记录。在一些示例中，存在使得该处理缩放更具挑战性的技术细节。例如，考虑事务T[10]正判断是否可以读取数据元素的版本x[8]的情况。已知x[8]由T[8]写入，并且T[8]在T[10]之前开始。然而，(根据x[8]本身)并不知晓T[8]提交的时间或者T[8]究竟是否提交。尽管T[10]从x无法直接获得T[8]的提交信息，但T[10]可以从本地事务管理器114内所存储的T[8]的记录中获得该信息。将存在以下四个情况其中之一：

1.T[8]仍是活动的(并且本地事务管理器114知晓T[8]仍是活动的)。在这种情况下，T[10]不能读取x[8]。

2.T[8]正中止(并且本地事务管理器114知晓T[8]正中止)，但该中止尚未“撤消”x[8]。在这种情况下，T[10]不能读取x[8]。

3.T[8]在T[10]开始之前提交，这意味着T[8]是T[8,9]。在这种情况下，T[10]可以读取x[8]。

4.T[8]在T[10]开始之后提交，使得T[8]是(即)T[8,12]。在这种情况下，T[10]不能读取x[8]。

该挑战来自于上述的点3和4。特别地，本地事务管理器114将事务的事务状态维持在内存中(以供高效访问)。点3和4暗示了本地事务管理器114必须在T[8]提交之后的一段时间内维持T[8]的事务状态。这样对长期服务器进程造成了问题。具体地，本地事务管理器114必须使T[8]的状态维持了促进可见性计算所需的时间长度，并且本地事务管理器114不能无限期地维持该状态，否则服务器进程将耗尽内存并且崩溃。

为了防止内存耗尽，分布式数据库系统102中的本地事务管理器114周期性地清除“旧的”事务状态(即，事务的旧记录)。本地事务管理器114采用两个清除策略：覆盖最常见情况的算法高效策略(“快速清除”)、以及针对快速清除不充分的情况的不太高效但更彻底的策略(“彻底清除”)。

通常，清除机制可以依赖于“全局低水位线”的概念。如下所述定义全局低水位线：设T[i]是系统中的最旧活动事务，并且设T[j]是T[i]开始时的最旧活动事务。全局低水位线是j。在关注事务记录清除的情况下，全局低水位线暗示了以下内容：事务标识符小于j的任何事务必须在很久以前提交，使得不会再次需要该事务的状态信息来进行可见性计算。

1.9.1快速清除

在快速清除算法开始之前，节点108的本地事务管理器114包括按提交标识符排序后的已提交事务的列表。该列表包含为了可见性计算而可能需要的所有已提交事务。为了开始快速清除处理，本地事务管理器114将网络消息发送至分布式数据库系统102的全局事务管理器116，从而请求分布式数据库系统102的全局低水位线和全局活动事务的列表。全局事务管理器116向本地事务管理器114回应包括所请求信息的消息。本地事务管理器114处理已提交事务的列表，包括将各已提交事务的提交标识符与全局低水位线进行比较。将具有比示例性全局低水位线小的提交标识符的任何已提交事务从本地事务管理器114中清除。在一些示例中，快速清除算法是具有早期终止条件的线性一遍(one-pass)算法。在单个本地事务管理器上，快速清除算法能够检查正确操作所需的最小数量的事务。

参考图39，分布式数据库系统202的一部分包括第一节点108a、第二节点108b和第五节点108c。将第二节点108b指定为分布式数据库系统202的领导节点。第一节点108a的本地事务管理器114a包括第一节点108a处先前完成的事务的五个本地记录：第一本地记录2840即T[100,120]、第二本地记录2842即T[63,80]、第三本地记录2844即T[50,62]、第四本地记录2846即T[25,35]和第五本地记录2848即T[20,30]。第五节点108c的本地事务管理器114c包括第五节点108c上活动的事务的两个本地记录：第六本地记录2850即T[110,FUTURE]和第七本地记录2852即T[53,FUTURE]。全局事务管理器116包括分布式数据库系统中活动的事务的两个全局记录：第一全局记录2854即T[110,FUTURE]:N₅和第二全局记录2856即T[53,FUTURE]:N₅。第一节点108a的本地事务管理器114a向全局事务管理器116发送了“清除请求消息”，从而请求分布式数据库系统102的全局低水位线和全局活动事务的列表。

参考图40，全局事务管理器116向“清除请求消息”回应例如全局低水位线(在这种情况下为48)和全局活动事务(例如，包括T[110]和T[53])的列表。为了进行可选的快速清除，本地事务管理器114a迭代事务的从最旧起直到最新为止的本地记录，并且将本地记录的提交标识符与示例性全局低水位线进行比较，以判断要清除哪些本地记录。在该示例中，将第五本地记录2848的提交标识符(即，30)与示例性全局低水位线(即，48)进行比较。由于30小于48，因此将第五本地记录2848从本地事务管理器114a中清除。接着，将第四本地记录2846的提交标识符(即，35)与全局低水位线(即，48)进行比较。由于35小于48，因此将第四本地记录2846从本地事务管理器114a中清除。然后，将第三本地记录2844的提交标识符(即，62)与示例性全局低水位线(即，48)进行比较。由于62大于48，因此第三本地记录2844未被清除，并且在这种情况下快速清除算法完成。

1.9.2彻底清除

在一些示例中，上述的快速清除算法对于事务按相对稳定的速率到达、执行并完成的工作负载而言是有效的。然而，并非所有的工作负载都必须具有这些特性。特别地，在一些示例中，快速清除算法对于长时间运行事务(即，生命期明显长于平均值的事务)的处理不佳。在这些示例中，本地事务管理器114使用彻底清除算法。

通常，一旦本地事务管理器114具有示例性全局低水位线和全局活动事务标识符的列表、并且可能已进行了快速清除算法，执行彻底清除算法。彻底清除算法可以迭代本地事务管理器114所存储的已提交事务的本地记录。对于各本地记录T[i,j]，本地事务管理器114可以迭代全局活动事务标识符的列表，并且将各全局活动事务标识符g与本地记录的事务标识符(即，i)和提交标识符(即，j)进行比较，以判断是否可以清除本地记录。通常，如果存在全局活动事务标识符g、使得i<g<j，则不能清除本地记录。如果没有识别出这种g，则可以清除本地记录。

注意，在存在g使得i<g<j的情况下需要维持T[i,j]暗示了以下内容：存在利用该特定本地事务管理器114没有加入的活动事务T[g]，但该活动事务T[g]与T[i,j]是并行的。如果T[g]要加入，则对于T[g]的可见性决策而言，可能需要T[i,j]的状态信息。

参考图41，(如图40所示)进行了快速清除算法，并且本地事务管理器114a具有全局活动事务T[53]和T[110]的列表。彻底清除算法迭代第一本地记录2840、第二本地记录2842和第三本地记录2844。

在彻底清除算法到达第一本地记录2840时，该算法将全局活动事务的列表的事务标识符(即，53和110)与第一本地记录2840的事务标识符(即，100)和提交标识符(即，120)进行比较，以判断是否可以清除第一本地记录2840。在该示例中，存在具有事务标识符“110”的全局活动事务。由于“110”落在第一本地记录2840的事务标识符(即，100)和提交标识符(即，120)之间，因此第一本地记录2840未被清除。

在彻底清除算法到达第二本地记录2842时，该算法将全局活动事务的列表的事务标识符(即，53和110)与第二本地记录2842的事务标识符(即，63)和提交标识符(即，80)进行比较，以判断是否可以清除第二本地记录2842。在该示例中，由于全局活动事务的事务标识符未落在第二本地记录2842的事务标识符(即，63)和提交标识符(即，80)之间，因此第二本地记录2842被清除。

在彻底清除算法到达第三本地记录2844时，该算法将全局活动事务的列表的事务标识符(即，53和110)与第三本地记录2844的事务标识符(即，50)和提交标识符(即，62)进行比较，以判断是否可以清除第三本地记录2844。在该示例中，存在具有事务标识符“53”的全局活动事务。由于“53”落在第三本地记录2844的事务标识符(即，50)和提交标识符(即，62)之间，因此第三本地记录2844未被清除。

在图41的示例中，在彻底清除算法完成时，将除第一本地记录2840和第三本地记录2844外的所有本地记录从第一节点108a的本地事务管理器114a中清除。

2实现

上述的分布式数据库系统可以例如使用执行适当软件指令的可编程计算系统来实现，或者可以在诸如现场可编程门阵列(FPGA)等的适当硬件中或者以某种混合形式实现。例如，在编程的方法中，该软件可以包括在一个或多个编程或可编程计算系统(可以具有诸如分布式、客户端/服务器或网格式等的各种架构)上执行的一个或多个计算机程序中的过程，其中该一个或多个编程或可编程计算系统各自包括至少一个处理器、至少一个数据存储系统(包括易失性和/或非易失性存储器和/或存储元件)、至少一个用户接口(用于使用至少一个输入装置或端口来接收输入，并且用于使用至少一个输出装置或端口来提供输出)。该软件可以包括例如提供与数据流图的设计、配置和执行有关的服务的较大程序的一个或多个模块。可以将程序的模块(例如，数据流图的元素)实现为符合数据存储库中所存储的数据模型的数据结构或其它有组织数据。

软件能够在一段时间(例如，诸如动态RAM等的动态存储器装置的刷新周期之间的时间)内以非暂时性形式(诸如在易失性或非易失性存储介质或任何其它非暂时性介质中体现)、使用介质的物理性质(例如，表面凹区和凸区、磁畴或电荷)存储。在为加载指令所作的准备中，软件可以设置在诸如(利用通用或专用计算机系统或装置可读取的)CD-ROM或其它计算机可读介质等的有形、非暂时性介质上，或者可以经由网络的通信介质(例如，以编码在传播信号中的形式)传递至执行该软件的计算系统的有形、非暂时性介质。可以在专用计算机上、或者使用诸如协处理器或现场可编程门阵列(FPGA)或专用特定用途集成电路(ASIC)等的专用硬件来进行一些处理或所有功能。可以以分布式方式来实现该处理，其中利用不同的计算元件来进行软件所指定的计算的不同部分。优选将每一个这种计算机程序存储在通用或专用可编程计算机可读取的存储装置的计算机可读存储介质(例如，固态存储器或介质、或者磁性或光学介质)上或者下载至该存储介质，以在利用计算机读取存储装置介质的情况下配置计算机并使该计算机进行工作以进行这里所述的处理。本发明的系统还可被视为作为配置有计算机程序的有形、非暂时性介质来实现，其中如此配置成的介质使计算机以特定的预定义方式进行工作，以进行这里所述的处理步骤中的一个或多个。

已经描述了本发明的许多实施例。然而，应当理解，前述描述旨在示出而不是限制本发明的范围，该范围由所附权利要求书的范围限定。因此，其它实施例也在所附权利要求书的范围内。例如，可以在不偏离本发明的范围的情况下作出各种修改。另外，上述步骤中的一些可以是与顺序无关的，因此可以按照与所描述的顺序不同的顺序执行。

Claims

1.一种用于管理包括多个节点的分布式数据库系统中的事务的方法，所述方法包括以下步骤：

在所述多个节点中的第一节点处维持多个事务的记录，各事务在所述多个节点中的一个或多个节点上执行，各记录具有多个事务状态中的事务状态，所述多个事务的记录包括第一事务的记录和第二事务的记录，在所述多个节点中的第二节点处执行所述第一事务包括用于访问所述第二节点上所存储的第一数据元素的操作，以及在所述第二节点处执行所述第二事务包括用于访问所述第二节点上所存储的第一数据元素的操作；

在所述第二节点处从所述第一节点接收包括所述多个事务中的在所述第二节点上执行并且在所述第二事务的发起时间具有第一事务状态的任何事务的事务列表，所述事务列表包括所述第一事务；

至少部分基于所述事务列表来判断为所述第二事务的结果取决于所述第一事务的结果；

基于判断为所述第二事务的结果取决于所述第一事务的结果而使所述第二事务的执行暂停，以及

在所述第一事务完成之后继续所述第二事务的执行。

2.根据权利要求1所述的方法，其中，至少部分基于所述事务列表来判断为所述第二事务的结果取决于所述第一事务的结果包括：

判断为所述第一事务的发起时间发生在所述第二事务的发起时间之前，并且所述第一事务的提交时间发生在所述第二事务的发起时间之前。

3.根据前述权利要求中任一项所述的方法，其中，所述事务列表是在所述第二事务的发起时间在所述第二节点处接收到的。

4.根据权利要求1或2所述的方法，其中，所述事务列表中所包括的事务包含在所述第二节点上执行并且在所述第二事务的发起时间具有所述第一事务状态的事务。

5.根据权利要求1或2所述的方法，其中，所述事务列表针对所述事务列表中的各事务包括该事务的发起时间。

6.根据权利要求1或2所述的方法，其中，所述第一事务状态表示事务正准备完成。

7.根据权利要求1或2所述的方法，其中，所述第一事务写入所述第一数据元素并且所述第二事务读取所述第一数据元素，并且利用所述第二事务所读取的所述第一数据元素的版本取决于所述第一事务的结果。

8.根据权利要求7所述的方法，其中，所述第一事务的可能结果包括事务中止结果和事务提交结果。

9.根据权利要求8所述的方法，其中，继续所述第二事务的执行包括：

在所述第一事务的结果是所述事务中止结果的情况下，读取所述第一数据元素的第一版本。

10.根据权利要求8所述的方法，其中，继续所述第二事务的执行包括：

在所述第一事务的结果是所述事务提交结果的情况下，读取利用所述第一事务写入的所述第一数据元素的第二不同版本。

11.根据权利要求1或2所述的方法，其中，所述第一事务和所述第二事务其中之一或这两者访问所述多个节点中的第三节点上所存储的数据元素。

12.根据权利要求1所述的方法，其中，所述第一事务和所述第二事务这两者尝试写入所述第一数据元素，并且所述第二事务处于所述第一事务状态。

13.根据权利要求12所述的方法，其中，至少部分基于所述事务列表来判断为所述第二事务的结果取决于所述第一事务的结果包括：

判断为所述第二事务的发起时间发生在所述第一事务的发起时间之后且发生在所述第一事务的提交时间之前。

14.根据权利要求12所述的方法，其中，所述第一事务计划在所述第二事务之前提交写入，其中，所述第二事务是否中止取决于所述第一事务得到事务中止结果还是事务提交结果。

15.根据权利要求14所述的方法，其中，继续所述第二事务的执行包括：

在所述第一事务的结果是所述事务中止结果的情况下，写入所述第一数据元素的第一值。

16.根据权利要求14所述的方法，其中，继续所述第二事务的执行包括：

在所述第一事务的结果是所述事务提交结果的情况下，中止所述第二事务。

17.一种计算机可读介质，用于以非暂时性的形式存储软件，所述软件用于管理包括多个节点的分布式数据库系统中的事务，所述软件包括用于使计算系统进行以下操作的指令：

在所述第一事务完成之后继续所述第二事务的执行。

18.一种用于管理事务的设备，所述设备包括：

多个节点，其配置在分布式数据库系统中，各节点包括至少一个处理器；以及

通信介质，用于连接所述多个节点的端口以在所述多个节点之间发送和接收信息，

其中，所述多个节点中的第一节点被配置为维持多个事务的记录，各事务在所述多个节点中的一个或多个节点上执行，各记录具有多个事务状态中的事务状态，所述多个事务的记录包括第一事务的记录和第二事务的记录，在所述多个节点中的第二节点处执行所述第一事务包括用于访问所述第二节点上所存储的第一数据元素的操作，以及在所述第二节点处执行所述第二事务包括用于访问所述第二节点上所存储的第一数据元素的操作，

所述第二节点被配置为从所述第一节点接收包括所述多个事务中的在所述第二节点上执行并且在所述第二事务的发起时间具有第一事务状态的任何事务的事务列表，所述事务列表包括所述第一事务，

所述第二节点被配置为至少部分基于所述事务列表来判断为所述第二事务的结果取决于所述第一事务的结果，以及

所述第二节点被配置为基于判断为所述第二事务的结果取决于所述第一事务的结果而使所述第二事务的执行暂停，以及

在所述第一事务完成之后继续所述第二事务的执行。