不间断事务处理系统的制作方法

专利名称：不间断事务处理系统的制作方法
技术领域：
本发明涉及不间断事务处理系统。更详细的讲，涉及用于不间断 事务系统构筑的事务处理方法、处理系统及其控制程序。
背景技术：
在当前的业务类系统中，由于服务器等的系统故障而暂时停止事 务处理成为一个很大的问题。为此，例如在专利文献l中，公开了诊 断并自我修复服务器中心(服务器群的组)中的服务器故障的方法以 及系统。
专利文献1:特开2004 - 110790号7>报
从系统的利用者来看，即使发生系统故障，但如果在相对于正常 的时候没有改变的时间内(大多系统中是2、 3秒)完成事务处理则 没有问题，但是在一般的系统中，难以使停止时间收敛在上述的时间 以内。
当前的业务系统的抗故障机构以故障检测和移交处理为基本。 即，釆用如果检测出故障则立即进行切换的方式。然而，在故障检测 方面一般需要10秒~几分钟。这是因为故障检测经由通信，以外部 计算机与对象服务器的消息交换是否拖延来进行判断。
然而，即使对象服务器正常动作，但有时由于负栽暂时较高，消 息交换发生拖延，因此在某个时间内试行若干次消息交换，这样做也 不能正常进行消息交换的情况下，判断为在对象服务器中发生了故 障。如果把该应答等待时间或者试行次数设定为过小，则尽管对象服 务器正常进行动作，但故障检测机构也判断为发生故障，开始在备用 服务器中的移交处理。因此，在生存确认方面，至少设置10秒左右 的时间。因此，不能在从利用者来看不知道系统故障的程度的时间内进行 故障检测和移交。这一点在故障检测中是本质性的。为了进一步缩短 用于生存确认的时间，需要准备生存确认的消息处理专用的网络，进 而，在对象服务器中准备了生存确认专用的处理器的基础上，需要用 于确认操作系统或者其上的处理是否正常进行动作的机构。然而这需
要变更硬件和操作系统，当前状况下的开放式平台(open flatform ) 的环境不能响应要求。

发明内容
从而，本发明是为解决上述课题而完成的，其目的在于提供不等 待系统的故障检测，在一定时间没有应答的情况下，能够向备用系统 再次发送处理的新的事务处理方法等。
在本发明中，主要设想下面那样的条件。
由一个数据管理机构和更新该机构中的数据的一个以上的服务 器构成的组(以下，把该组称为服务器中心(server farm))存在(2F + 1)组(F是自然数)。关于该服务器中心的组存在发行事务请求的 客户端，各服务器中心之间、客户端与服务器中心之间，经由具有多 条数据发送路径的冗余化(多重化)了的网络被连接。能够从一个客 户端投入多次同 一事务的请求，客户端在等待一定时间也没有得到来 自一个服务器中心的应答的情况下，向其它的服务器中心发送同一个 事务的请求。另外，虽然任意的网络以及服务器中心随时有可能成为 功能不全，但是由于故障而陷入功能不全的最多只有F组的服务器中 心。
图1表示了本发明设想的系统基本形式(相当于F = 1的情况)。 如在这里所示，在各服务器中心1 3中，分别存在多个应用服 务器(lc~3c)、各服务器中心中的一个数据库(DBla、 2a、 3a )和 管理其DB的DB服务器(lb、 2b、 3b)。请求事务的客户端4、 5 经由各服务器中心内的应用服务器和DB服务器，访问事务所需要的 数据库。图2表示了本发明设想的最小的结构。图中的仲裁器(arbiter) 8是服务器中心的特殊形式，是仅为了使其它的服务器中心正常工作 的不进行事务处理也不具有DB的服务器中心。例如，在F-l的情 况下，虽然在本发明中需要3个服务器中心，但不需要把DBMS(数 据库管理系统)三重化的情况也很多。而本发明由于以基于多数决定 的分散合意协议为基础，因此需要即使在二重化的情况下，也进行针 对多数决定的投票的服务器。进行该动作的是仲裁器8。
以下，以(2F + 1)组(奇数组)为基本说明服务器中心，而通 过这样在结构中包括仲裁器8，在2F组(偶数组)的服务器中心的系 统中也能够应对。
本发明的课题在这样的条件下，保证下面的3点。
<课题1>即使在多次重复执行同一个事务的情况下，最多有一 个执行在提交中成功(完成提交)。
<课题2 >根据最新的数据执行提交完成了的事务。
<课题3>即使某个服务器中心由于故障而停止，也不会长时间 停止这些事务处理而能继续进行。
为了解决这样的课题，在本发明的第1实施形态中提供以下的处 理方法。
(l)在事务开始处理中，处理下述步骤的方法。 步骤1:在事务开始处理中，参照对象事务的ID，确认是否已 经正在执行同一个ID的事务，或者提交已经完成，如果是正在执行 或者提交已经完成，则回退(取消)对象事务。
步骤2:进而，在事务开始处理中，自身服务器中心确认是否保 持着没有用尽有效期间的处理权限Token (带时间限制的Token ), 如果没有保持它，则使用「在2F + 1台的服务器群中的利用了处理权 限Token的排斥控制技术」，进行处理权限Token的取得处理，等 待其取得完成。
步骤3:进而，在进行了上述的处理权限Token的取得处理的情 况下，在该处理的同时，或者紧接在其以后，使用r在2F + l台的月良务器群中的取得数据匹配的技术」，自身服务器中心在系统内的所有 的服务器中心之间保持最新的数据。
这里，「在2F + 1台的服务器群中的利用了处理权限Token的 排斥控制技术」和r在2F + 1台的服务器群中的取得数据匹配的技术J 如后所述，使用公知技术。
另外，是除去(1)的处理以外，还处理(2)的步骤的方法。 (2)在事务的提交处理中，执行下述的处理流程。
步骤l:在提交处理中，使用「2F + 1台的服务器群中的更新数 据的复制技术」，向所有的服务器中心传送对象事务的事务ID、该事 务更新了的数据、向该事务的请求源返送的处理结果，确认至少对于 F + l台的服务器的拷贝。
步骤2:进而，在步骤l成功了的情况下，使用r在2F+l台的 服务器群中的基于分散合意的能否提交的判断技术」，向其它所有的 服务器发送提交请求消息，如果至少接收到来自F + l台服务器的提 交合意，则当作提交成功。
步骤3:进而，使所有的服务器中心知道提交被确定了。
这里，「在2F + 1台的服务器群中的更新数据的复制技术J和 r在2F + 1台的服务器群中的基于分散合意的能否提交的判断技术J 如后所述，使用公知技术。
(1)和(2)表示本发明的主要处理，进而作为添加的处理，包 括以下的方法。
(3 )在处理权限Token取得处理中接收到提交请求消息的情况 下，直到处理权限Token取得处理完成为止，不进行针对提交请求消 息的应答，或者，应答提交请求消息的再次发送委托的处理。
(4) 在向其它的服务器中心发送提交请求消息，接收其应答而 确定提交为止的期间中，在接收到处理权限Token取得消息的情况 下，直到提交确定为止，不进行针对处理权限Token取得消息的应答， 或者，应答处理权限Token取得消息的再次发送委托的处理。
(5) 在处理权限Token取得完成之前，从其它服务器取得未确定的事务的日志，使事务日志的状态同步的处理。(6 )在处理权限Token取得消息的接收处理以及其应答消息的 接收处理中，在消息内包括提交不明确的事务信息的情况下，参照该 信息，在该事务的提交或者回退已经确定了的情况下，返送其结果， 在还没有确定的情况下，根据(2)的方法，进行提交确定的处理。(7)作为事务的提交请求消息的接收处理，判断其消息的发送 源以外是否保持着有效的处理权限Token,如果是保持着，则对于提 交请求应答拒绝，如果没有保持，则对于提交请求应答承认的提交请 求承认处理。(8 )根据事务处理的应答时间的估计值计算发送事务处理请求 的客户端的事务的再次发送时间和用r在2F + l台的服务器群中的利 用了处理权限Token的排斥控制技术」设定的Token的有效期间， 设定到客户端一侧的再次发送.Token有效期间设定处理。以上作为事务处理方法说明了本发明的解决方法的一个实施形 态，而作为其它的实施形态，能够通过具有同样功能的处理装置、处 理机构(处理系统)以及控制它们的计算机程序实现。在本发明中提出了，不等待故障检测，在一定时间内没有应答的 情况下，从客户端向备用的服务器中心再次发送处理的系统。即，本 发明的事务处理具备把使用了处理权限Token的排斥控制和数据匹 配组合起来的事务开始处理、把基于分散合意的能否提交判断和更新 数据的复制组合起来的提交处理。根据该处理，能够比现有技术更缩 短由应用服务器、DBMS (数据库管理系统)、网络中发生的故障引 起的服务停止时间，能够构筑客户端不必识别故障发生，就可以继续 服务的系统。


图l表示事务处理系统的基本形式。 图2表示事务处理系统的最小结构。 图3表示F-1时的Paxos提交的结构例。图4表示本发明一个实施形态的系统结构和提案机构的位置的例子。
图5表示本发明一个实施形态的事务处理系统。
图6表示最初和备用的服务器中心的消息的收发处理单元。
图7表示Token请求发送单元61的处理流程。
图8表示Token应答接收单元62的处理流程。
图9表示Token请求处理单元63的处理流程。
图10表示Token请求处理63的处理流程(继续)。
图11表示提交请求发送单元64的处理流程。
图12表示提交请求应答接收单元65的处理流程。
图13表示提交请求处理单元66的处理流程。
(附图标记说明) 1、 2、 3服务器中心 la、 2a、 3a DB lb、 2b、 3b DB服务器 lc、 2c、 3c应用服务器 4、 5客户端 8仲裁器 40服务器中心 41应用服务器 42 DB服务器 45事务前端机构 46事务后端机构 46b提案机构 50事务处理系统 51事务开始处理机构 51a控制单元 51b事务重复检测单元 51c Token排斥控制单元51d数据匹配处理单元 52提交处理机构 52b数据复制处理单元 52c提交确定处理单元 52d提交发送单元 53有效期间设定机构 53a控制单元
53b事务再次发送时间设定单元 53c Token有效期间设定单元 53d客户端通信单元 60a最初服务器中心 60b备用服务器中心
61 Token请求发送单元
62 Token应答接收单元
63 Token请求处理单元 64提交请求发送单元
65提交请求应答接收单元
66提交请求处理单元
67a处理权限Token取得请求消息
67b处理权限Token取得请求应答消息
68a提交请求消息
68b提交请求应答消息
70处理权限Token取得请求消息发送处理
80对于处理权限Token取得请求的应答消息接收处理
90处理权限Token取得请求消息接收处理
IIO提交请求消息发送处理
120对提交请求的应答消息接收处理
130提交请求消息接收处理
具体实施例方式
在本发明中，提供同时解决已经叙述过的3个课题，保证必须在 一个服务器中心中进行某个事务的提交，进而，保证提交成功的事务 始终对于最新的数据进行的事务处理。本发明的基本原理如下。
<课题1的解决技术>
为了防止在多个服务器中心中多重处理某个事务，使用在下述的 文献1 ~ 3中提出的基于Mutual Exclusion技术的r处理权限Token J。
1) Suzuki, I, Kasami, T, A distributed mutual exclusion algorithm, ACM T ransactions on Computer Systems (TOCS), v.3 n.4, p,344—349, Nov. 1985.
2) Nishio, S., Li, K.F., Manning, E.G., A resilient mutual exclusion algorit hm for computer networks, IEEE Transactions on Parallel and Distributed S ystems， v.l n.3 , p.344-355, July 1990.
3) Banerjee, S.; Chrysanthis, P,K., A new Token passing distributed mutua 1 exclusion algorithm, Proceedings of the 16th International Conference on Distributed Computing Systems, 1996.， p.717-724, May 1996.
Mutual Exclusion技术是在多个服务器群(服务器中心)中，使 得只有一个服务器能够保持Token的通用化了的技术。在本发明中， 使用该技术，在某个时刻具有有效的处理权限Token的服务器中心在 2F + 1个服务器中心内仅存在1个。在某个服务器中心的提交处理时， 在不具有有效处理权限Token的情况下，其服务器中心尝试再次取得 处理权限Token,在不能取得的情况下，回退(rollback)事务。在 处理权限Token中设定有效期限。如果该有效期限用尽，则其处理权 限Token成为无效，其它的服务器中心能够重新取得处理权限Token 。 在典型的情况下，为了缩短由故障引起的系统的停止时间，将处理权 限Token的有效期间设定为1秒左右。但也能延长处理权限Token 的有效期间。
<课题2的解决技术>
在本发明中，使用在2F + 1台的服务器群内的F台以上的服务 器中拷贝数据的(由于自身服务器中心也具有数据，因此在整体上成为过半数、即F+l台以上的服务器中心具有数据)数据复制技术， 以及把2F + 1台的服务器群内的F + l台以上的服务器群具有的数据 作为2F+1台的服务器群中的合意完毕的数据来处理的数据匹配技术。这些技术是已经公知的通用化的技术(文献4、 5)。4) 丄 Gray and A. Reuter, Transaction Processing Concepts and Technique s, Mogem KEiufiimnn5) M. Wiesmann, F. Pedone, A. Schiper， B. Kemme, and G, Alonso Unde rstanding replication in databases and distributed systems. In Proceedings of20th International Conference on Distributed Computing Systems 〔ICDCS' 2000〕， p.264—274， April 2000.<课题3的解决技术>在事务的提交处理中，较出名的有2相提交协议(Two-Phase Commit Protocol)，而其作为Blocking协i义也4皮熟知。所谓Blocking 协议是如果进行事务的提交处理的协调器(coordinator)由于故障而 停止，则其事务的提交成为未确定，在取得该协调器的决定结果之前 不能确定事务的提交处理的协议。从而，在该协议中，不能解决课题 3。 J. Gray等作为解决该问题的技术提出了在提交处理中应用了 L. Lamport等提出的采取2F + 1台的服务器群中的合意的Paxos共识协 议(文献6 )的Paxos提交协议(文献7 )。该协议是如果2F + 1台 的服务器群内的F + l台以上的服务器正常工作，则能够无阻塞地完 成提交处理的协议。在本发明中，作为解决课题3的提交处理技术，利用Paxos提交。6) L, Lamport, Generalized Consensus and Paxos, Microsoft Research Technical R印ort MSR-TR-2005-337) J. Gray and L. Lamport, Consensus on Transetction Commit, MSR-TR-2 003-96)<课题1~3整体的解决>课题l、 2、 3分别存在解决的技术。然而，在本发明中，必须同 时解决这些全部的3个课题。即使单独利用课题1~3的各个解决技 术，也不能同时解决全部的课题1~3。例如，在解决课题1的MutualExclusion中，能够防止同一事务的多重处理，但是不能保证进行了 提交的事务处理对于2F+1台服务器群中的最新的数据集合进行。在 解决课题2的数据复制技术以及数据匹配技术中，不能防止同一事务 的多重处理。在解决课题3的Paxos提交中，既不能解决同一事务的 多重处理，也不能保证对于2F + 1台的服务器群中的最新的数据集合 进行提交处理。从而，为了同时解决全部的课题1~3，需要把解决各 个课题的技术适当地融合，重新建立算法。在本发明的事务处理机构中，在事务的开始时，进行用于防止事 务的多重处理的处理权限Token的确认处理。在具有处理权限Token 的情况下，事务的开始处理结束。不具有处理权限Token的服务器中 心进行处理权限Token取得处理和数据匹配处理这两种处理。处理权限Token取得处理按照Mutual Exclusion中表示的方法 进行。在失败的情况(其它服务器中心已经取得的情况)下，使事务 的开始处理失败。在Mutual Exclusion中，对于处理权限Token取得 请求，如果可以得到来自F + 1个服务器中心的合意，则能取得Token。从而，2F + 1个服务器中心中能够取得处理权限Token的服务器 中心必定只是一个。另外，即使最多F个服务器中心(例如服务器中 心中的DB服务器)停止，也能够进行处理权限Token取得。提供处 理权限Token的单位典型的是应用单位，而严密地讲，是对于这样的 数据集合提供，即，作为某个事务的集合所访问的数据集合，该事务 集合以外的事务不进行访问，而且该事务集合内的任意的事务对该数 据集合以外的数据不进行访问的数据集合。接着为了对最新的数据进行事务，在处理权限Token取得处理 时验证取得权限的服务器中心是否具有最新的数据，在不具有的情况 下，进行从其它的服务器中心取得表示数据差分的事务日志的处理。 在本发明中，如果能够对于F + l个服务器中心拷贝事务日志，则能 够成功提交。从而，在2F + 1个服务器中心内的F + l个服务器中心具有的事务日志的集合中必定存在最新的事务日志。这里，通过在事 务日志上提供连续号码LSN (日志系列号)，能够把握取得了处理权限Token服务器中心不具有的事务曰志，能够从服务器中心群搜索和 取得。在事务的提交处理中，进行数据复制处理和提交确定处理。 首先，在数据复制处理中，进行事务日志的拷贝，使得F + 1个以上的服务器中心具有事务日志。向生存的所有服务器中心传送事务曰志，等待接收来自F个服务器中心的确认消息。接着，提交的确认处理根据Paxos提交进行。进行提交处理的服务器中心向生存的其它所有服务器中心发送r Prepare J消息。接收到该消息的各服务器中心在判断为其发送源服务器中心以 外具有处理权限Token的情况下，作为r Abort」，没有的情况下作 为r prepared J ,把决定结果发送到自己的称为接受器(acceptor)的所有模块中。这里，所谓接受器是仅具有对于某个服务器中心的提 交的决定结果的服务器，在每一个服务器中心中准备2F+1个接受器。 接收到服务器中心的决定结果的接受器把该结果发送到正在进行提 交处理的服务器中心。该服务器中心如果从某个服务器中心的接受器 中的F + l个以上的接受器接收到了决定结果，则就作为该服务器中 心的决定结果来处理。图3表示本发明情况下F-l中的Paxos提交的结构例。其中， 图3中省略了从接受器向提交处理执行^f莫块的箭头。这里，位于一个服务器中心中的各模块(31a、 31b、 32a、 33b) 以及接收器(31c、 31d、 31e、 32c、 32d、 32e、 33c、 33d、 33e )既可 以配置在相同的服务器装置中，也可以配置在不同的服务器装置中。这里，分别说明了处理权限Token取得、数据匹配化、数据复 制、提交确定，实际上，由于在各个处理中进行消息交换，因此消息 数增多而有可能使性能降低。但是，如果考虑到在事务开始处理中， 进行处理权限Token取得和数据匹配，在提交处理中进行数据复制和 提交确定，这些处理全部以取得来自2F + 1个服务器中心之间的F + 1个服务器中心的合意的所谓分散合意协议为基础，则可以把用于事 务开始处理的处理权限Token取得处理和数据匹配的发送消息和接收消息汇总为一个消息，并且，把提交处理的数据复制和提交确定的 发送消息和接收消息也汇总为 一个消息，能够防止由消息数增加引起 的性能下降。其中，汇总这种消息的动作是通常进行的动作。该一系列的处理如果只是简单地结合对于课题1~3的技术，则 不能起到作用。问题是某个服务器中心开始事务，在其进行提交处理 之前用尽处理权限Token的有效期限的情况。这种情况下，其它的服 务器中心能够取得处理权限Token。现在设服务器中心1具有处理权限Token,开始了事务A的提 交处理，而在事务A的提交处理结束之前用尽了处理权限Token的 有效期限。这种情况下，其它的服务器中心2能够取得处理权限 Token,执行新的事务B，能够开始提交处理。这里，如果事务A和 B成功提交，则数据的匹配性变紊乱。由于事务A更新的数据的提交没有确定，因此没有反映到服务 器中心2中。从而，事务B对于进行事务A之前的数据集合进行。这 里，如果事务B进行提交，紧接在其后事务A的提交结束，则有可能 丢失事务B的结果。为了防止这一点，在服务器中心2取得处理权限 Token的时刻，需要保证服务器中心1中正在处理的事务是确定的， 或者回退在服务器中心1中正在处理的事务。在本发明中，把对于课题1~3的各个解决技术结合起来，使得 保证以上的内容。在本发明中，客户端等待来自服务器的应答结果的暂停时间和处 理权限Token的有效期限的设定是重要的。当客户端向备用的服务器 中心再次发送了事务处理请求时，已经用尽了最初(primary)的服 务器中心的处理权限Token的有效期限的情形下由于立即进行备用 的处理权限Token取得，因此效率良好。反之，在处理权限Token 的有效期限与直到客户端再次发送为止的暂停时间相比过长的情况 下，备用的服务器中心中的处理权限Token取得不成功，客户端向下 一个备用的服务器中心再次发送。这种情况下，在用尽了处理权限 Token的有效期限的瞬间，多个服务器中心同时想要取得处理权限Token,成为相互竟争关系，其结果，有可能哪一个服务器中心都不 能取得处理权限Token。直到客户端的再次发送为止的暂停时间和处 理权限Token的有效期限考虑到这些问题，需要进一步考虑事务的平 均处理时间、最大等待时间等来决定。 <就系统结构的提案机构的位置>图4表示系统整体和本发明提出的机构的一个例子。这里，表示 提案机构46b处于服务器中心40中的DB服务器42内的情况。然而， 提案机构46b的位置不限于这种情况。本发明的事务处理机构由应用服务器41内的事务前端机构45 (以下，记述为事务Fr机构)和位于DB服务器42内的事务后端机 构46(以下，记述为事务Bk机构)构成。事务Fr机构在每一个事务中存储业务逻辑生成的事务日志，用 事务Fr机构的提交处理，向事务Bk机构传送存储的事务日志。这里， 调用本发明的提案机构46b，决定提交成功.失败。接着，事务Bk机 构如果提交成功，则使用事务日志经由DBMS47更新DB43。接着， 向事务Fr机构返送提交结果，应用的提交处理结束。这里，在事务 Fr机构与事务Bk机构之间不需要是2相提交。在事务Bk机构中，当在提案机构46b决定提交成功以后，更新 DB43时，在DB服务器42中发生故障，更新失败了的情况下，其服 务器中心功能停止，应用的提交处理成为不完全的状态(提交成功.失 败不明确)，而根据提案机构46b，事务日志向其它的服务器中心传 送，在其服务器中心中进行对DB43的更新。从而，客户端只要再次 发送事务处理请求即可。这里，该事务日志与数据更新的历史一起， 还保持向客户端返送的事务处理结果，当客户端再次发送了事务处理 请求时，如果该事务已经提交成功，则需要进行从该事务日志取得处 理结果，返送该结果的处理。另外，在事务日志中包括事务的处理结果的机构、以及来自客户 端的事务处理请求再次发送时从事务日志取出并返送事务处理结果 的机构由于不是本发明的主题因此省略说明。以下，研究本发明的替代方法。 <基于故障检测的方法>
当前最主流的方法是进行故障检测，进行移交处理这样的方法。
如前面叙述的那样，该方法由于在故障检测中至少需要10秒以上，
因此不能从客户端隐蔽故障。 <基于多重处理的方法>
这是在多个服务器中进行相同的处理，按照多数决定对其结果进 行比较，把同意数多的结果作为整体结果的方法。该方法在航空机等 要求可靠性非常高的系统中使用。然而，如果把该方法导入到事务处 理系统中，则如下所述，在性能上将产生很大的问题。
在该方式中，在相互依赖的多个事务处理请求几乎同时到达的情 况下，如果没有在所有的服务器中以相同的顺序进行处理，则所有的
数据管理机构所具有的数据不相同。例如，设现在有2个事务处理请 求A和B。 A、 B的处理分别是「如果数据X是0则使X成为1 ，如 果是0以外则不进行任何处理」、r如果数据X是l则使X成为10， 如果是l以外则不进行任何处理J 。这里，考虑在服务器中心1中按 照A、 B的顺序进行处理，在服务器中心2中按照B、 A的顺序进行 处理的情况。最初，设在2个服务器中心中数据X是0。在服务器中 心1中由于按照A、 B的顺序进行处理，因此X的值成为10，而在服 务器中心2中由于按照B、 A的顺序进行处理，因此X的值成为1。 在各个服务器中心中保持不同的结果这一点是不能接受的。
现实中，在相互依赖的事务或完全没有关系的事务相混合，事务 处理请求到达的阶段中，并不知道其与其它的哪个事务存在依赖关 系。因此，需要在所有的服务器中按照相同的顺序处理所有的事务处 理请求。为了实现这一点，在每次事务处理请求到达时，在所有服务 器中取得同步，进行顺序确认。进而由于在各服务器中，必须按照在 所有服务器中取得同步的顺序进行处理，因此按照其顺序一个一个地 处理所有的事务处理。这样做将使事务处理的工作效率急剧下降。
图5表示作为本发明的一个实施形态的事务处理系统(处理机构)的概略。
事务处理系统50是服务器中心内的主要遍及DB服务器、应用 服务器的处理机构。事务处理系统50如图所示，在功能上分为事务 开始处理机构51、事务提交处理机构52以及有效期间设定机构53。 有效期间设定机构53包括对于客户端或者应用服务器进行设定的机 构。
首先，事务开始处理机构51包括控制单元51a、事务重复检测 单元51b、 Token排斥控制单元51c、数据匹配处理单元51d。
事务重复检测单元51b在事务的开始处理中，参照对象事务的 ID，确认是否已经正在执行同一 ID的事务，或者已经完成提交，如 果是正在执行或者已经完成提交，则对于事务开始请求应答回退。
Token排斥控制单元51c在事务的开始处理中进行处理权限 Token的排斥控制，在该处理权限Token的排斥控制中，确认自身服 务器中心是否保持没有用尽有效期间的处理权限Token (带时间限制 的Token),如果没有保持，则进行处理权限Token的取得处理，等
待到其取得结束。
数据匹配处理单元51d在进行上述的处理权限Token的取得处 理时，与该处理同时或者紧接在其以后，控制自身服务器中心保持在 系统内的所有服务器中心之间最新的数据的数据匹配。
其次，事务提交处理机构52包括数据复制处理单元52b、提交 确定处理单元52c以及提交发送单元52d。
数据复制处理单元52b进行将对象事务的事务ID、该事务所更 新的数据和向该事务的请求源返送的处理结果向所有的服务器中心 传送，确认至少对于F + 1台服务器的拷贝的处理，管理各数据库的 复制处理。
提交确定处理单元52c控制这样的处理，即，在由数据复制处理 单元52b对于数据库的拷贝成功了的情况下，向其它所有的服务器发 送提交请求消息，如果接收到至少来自F + l台服务器的提交合意， 则作为提交成功的处理。进而，提交发送单元52d向其它所有的服务器中心发送该提交被 确定了的情况。进而，有效期间设定机构53包括控制单元53a、事务再次发送 时间设定单元53b、 Token有效期间设定单元53c、客户端通信单元 53d。事务再次发送时间设定单元53b是在从DB服务器看到的客户 端(应用服务器或者客户端终端)中设定事务的再次发送时间(最大 等待时间)的机构。例如，在系统构成时，可以向各客户端装置发送 存储再次发送时间的设定画面。Token有效期间设定单元53c是设定在系统内的各服务器中心内 使用的处理权限Token的有效时间的机构。即，以所给出的事务再次 发送时间为基准，提供设定Token的有效时间的单元。例如，可以在 系统结构设定画面中由管理者输入Token有效时间作为参数，进行所 输入的参数对于事务再次发送时间是否妥当的检查。关于这些设定时 间的参数的例子在后面叙述。另外，以上的处理机构终究是一个例子，并不限于该结构。图6表示由图5的事务重复检测单元51b决定了的最初一侧的服 务器中心与备用一侧的服务器中心之间的消息的交换。另外，该图表 示进行最初服务器中心60a与备用服务器中心60b的消息收发的以下 的各处理单元。最初服务器中心60a具备向备用服务器中心60b发送处理权限 Token取得请求消息67a的Token请求发送单元61、接收对于Token 取得请求的处理权限Token取得请求应答消息67b的Token应答接 收单元、发送提交请求消息68a的提交请求发送单元64以及接收提 交请求应答消息68b的提交请求应答接收单元65。另外，备用服务器中心60b具备从最初服务器中心接收Token 请求消息，发送对于该请求的应答的Token请求处理单元63、接收 提交请求消息的提交请求处理单元66。用后述的流程图说明上述各消息的发送单元、接收单元的细节。本发明的一个实施形态如用图5中说明过的那样，如果从实际安装的观点来看，由事务开始处理机构、提交控制机构、再次发送Token 有效期间设定机构(有效期间设定机构)这3个构成。 [l.事务开始处理机构]该机构的中心是处理权限Token的管理机构。处理权限Token基本上是这样一种机构，即，保证在某个时刻 具有该处理权限Token的服务器中心是一个，而且，保证即使在服务 器中心中发生故障，在系统整体中也不会漏掉事务的提交的结果而移 交给其余的服务器中心。在各服务器中心中，存在一个正在工作的处理权限Token管理 机构。在该机构停止的情况下，视为服务器中心的停止。提供处理权 限Token的单位对于这样的数据集合进行提供，即，作为某个事务的 集合访问的数据集合，该事务集合以外的事务不会进行访问而且该事 务集合内的任意的事务不会访问该数据集合以外的数据那样的数据 集合。典型地考虑应用单位。在本发明中，在处理权限Token管理中使用依据多数决定的保 持者决定方式。由此，即使一个服务器中心因故障而停止，也知道当 前哪个服务器中心保持处理权限Token。另外，在处理权限Token中设置有效期间。由此，即使当前正 在保持处理权限Token的服务器中心因故障而停止，但如果经过某时 间，其它的服务器中心能够取得处理权限Token,其它的服务器中心 能够执行事务处理。另外，在处理权限Token中设置作为连续号码(通番)的TSN (Token系列号)。另夕卜，如事务日志中已经叙述的那样，提供LSN(日志系列号)， 当取得处理权限Token时，保持了前一次处理权限Token的服务器 中心能够取得最终提交的事务日志。由此，能够不丢失提交完毕的事 务曰志而继续执行。以下表示取得处理权限Token的处理。<处理权限Token取得请求消息发送处理70 >本处理由图6的Token请求发送单元61进行。以下，参照图7 的流程图详细说明。1) 在有其它的服务器中心保持着处理权限Token这样的记录的 情况下(步骤S71:"是")，等待到该处理权限Token的有效期间 用尽为止(步骤S72)。2) 记录当前时刻，3) 决定处理权限Token的有效期间(步骤S73 )。4) 从当前记录在自身服务器中心中的最新的处理权限Token, 取得其TSN，根据下述的方法决定TSN，作为新的处理权限Token 的TSN提供。(a )如果判断为自身服务器中心直到紧接之前为止保持了处理 权限Token，则把其处理权限Token的TSN作为新的TSN(步骤S75 )。(b)否则的情况下，把在直到紧接之前为止的处理权限Token 的TSN上加1的值作为新的处理权限Token的TSN (步骤S76 )。5) 在自身服务器中心中，确定是提交还是回退，进而，在事务 曰志的LSN中没有遗漏地连续的事务日志的集合内提供事务日志的 LSN的最大值和处理权限Token的有效期间，向自身以外的所有服务 器中心发送处理权限Token取得请求(步骤S77 )。<对于处理权限Token取得请求消息的应答消息接收处理80 >本处理由图6的Token应答接收单元62进行。以下，参照图8 的流程图详细说明。1)当对于接收到的处理权限Token取得请求的应答消息内的事 务曰志的LSN与在自身服务器中心中在事务曰志的LSN中没有遗漏 地连续的事务日志的集合内的事务日志的LSN的最大值相比更大的 情况下(步骤S81:"是")，从处理权限Token取得请求的应答消 息，取出差分的事务日志，反映数据(步骤S82)。2 )如果从一个以上的服务器中心接收到处理权限Token取得许 可(步骤S83:"是")，则作为处理权限Token取得成功，把在步 骤S73中记录了的时刻上加上处理权限Token的有效期间的时刻作为处理权限Token的有效期限进行记录(步骤S84)。进而，取得应答 消息内的处理权限Token的TSN，把其值和在步骤S75、 S76中提供 的值中的大的值作为处理权限Token的TSN记录后结束(步骤S85 )。 3)在接收到来自2个服务器中心的处理权限Token取得拒绝的 情况下(步骤S86:"是")，作为处理权限Token取得失败而结束。 4 )在接收到再次发送委托，并且还没有能够取得处理权限Token 的情况下(步骤S87:"否")，判断是否应该再次发送，如果应该 再次发送(步骤S89:"是")，则等待一定时间，从步骤S71开始 执行(仅在接收到再次发送委托的情况下到达该步骤)。5)在即使经过某一定时间也不能决定处理权限取得的成功 失 败的情况下(步骤S88:"否")，作为处理权限Token取得失败， 判断是否应该再次发送，如果应该再次发送(步骤S89:"是")， 则经过一定时间以后，从步骤S71起再次执行。以下，表示对于处理权限Token取得请求的接收处理的算法。 <处理权限Token取得请求消息接收处理卯> 本处理由图6的Token请求处理单元63进行。以下，参照图9、 图10的流程图详细说明。1) 如果自身服务器中心正在进行处理权限Token取得处理(步 骤S91:"是")，则返送再次发送委托后结束(步骤S92)。2) 把处理权限Token取得请求的消息内的事务日志的LSN与 自身服务器中心保持的事务日志的LSN中没有遗漏而连续的LSN的 集合的最大值进行比较，进行以下的处理。(a) 在自身服务器中心的事务曰志的LSN大的情况下(步骤 S93:"是")，把发送源的服务器中心不具有的事务日志加入到应 答消息中(步骤S94)。(b) 在自身服务器中心具有当前正在提交处理的事务，其事务 曰志的LSN比接收到的事务曰志的LSN小的情况下(步骤S95:"是，，)，将该事务设为提交结束(步骤S96)。3 )在自身服务器中心具有有效期限内的处理权限Token的情况下(步骤S97:"是")，把处理权限Token取得拒绝加入到应答消 息中，返送后结束(步骤S98)。4) 在自身服务器中心具有发送源服务器中心以外的服务器中心 具有有效期限内的处理权限Token这样的记录的情况下(步骤S99:"是")，把处理权限Token取得拒绝加入到应答消息中返送后结束 (步骤S100)5) 在自身服务器中心具有正在提交处理的事务的情况下(步骤 S101:"是")，把再次发送委托加入到应答消息中，返送后结束(步 骤S102)。6) 把在当前时刻上加上提供到处理权限Token取得请求的有效 期间的时刻作为处理权限Token的有效期限进行记录，进而根据下述 的方法，决定新的处理权限Token的TSN,记录其值(步骤S103 )。(a) 在接收到的处理权限Token取得消息内的TSN比在自身 服务器中心中记录的最新的处理权限Token的TSN大的情况下(步 骤S104:"是")，把接收到的处理权限Token取得消息内的TSN 作为新的处理权限Token的TSN (步骤S105 )。(b) 在接收到的处理权限Token取得消息内的TSN与在自身 服务器中心中记录的最新的处理权限Token的TSN相同，发送源的 服务器中心与在自身服务器中心中记录的保持最新的处理权限Token 的服务器中心相同的情况下(步骤S107:"是")，把在自身服务器 中心中记录的最新的处理权限Token的TSN的值作为新的处理权限 Token的TSN (步骤S108 )。(c) 在不属于上述2种情况时，把在自身服务器中心的处理权 限Token的TSN上加1的值作为新的处理权限Token的TSN (步骤5109) 。7) 把"处理权限Token取得明白"和在步骤S103 ~ S109中决定 了的处理权限Token的TSN加入到应答消息中，返送后结束(步骤5110) 。由于在处理权限Token中存在有效期间，因此如果经过该期间，则当前的处理权限Token成为时间用尽，即使保持该处理权限Token 的服务器中心变为功能不全，下一个服务器中心也能获得处理权限 Token。
这里，重要的一点在于在发送源服务器中心中，把处理权限 Token的有效期限取为在请求发送前的时刻上加上了处理权限Token 的有效期间得到的值，而且，在接收了请求一侧的服务器中心中，取 为在该请求的接收时刻上加上了处理权限Token的有效期间得到的 值。由此，在接收一侧，保证在处理权限Token成为期限用尽的时刻， 已经用尽当前的处理权限Token的有效期限。即，即使不确认保持当 前处理权限Token的服务器中心生存这一点，其它的服务器中心也能 确认处理权限Token的有效期限用尽，能够对取得下一个处理权限 Token或者取得请求发出许可。 [2.提交控制机构]
在提交处理中，向其它2个服务器中心发送事务日志，如果从一 个以上的服务器中心接收到"明白，，则作为提交成功。由于假定服务器 中心是3个，因此如果发送了事务日志的服务器中心和其它另 一个服 务器中心进行"提交明白"，则可以得到过半数的"提交明白"，从而能 够以来自 一个以上的服务器中心的"提交明白"，作为系统整体可明白 提交。
以下表示提交处理。这里，设在事务上提供了在系统内成为唯一 的事务ID。另外，在下述的算法中没有包括对客户端的返送处理，但 在提交处理结束以后，对客户端应答事务的处理结果。这时，即使开 始了提交处理的事务进行回退，当已经存在具有同一事务ID的事务 日志时，从该事务日志取得处理结果返送给客户端。
<提交请求消息发送处理110 >
本处理由图6的提交请求发送单元64进行。以下，参照图11 的流程图详细说明。
1)如果已经在自身服务器中心中对于同一个事务完成了提交处 理(步骤S111:"是，，)，则应答回退后结束(步骤S112)。2) 如果已经从其它服务器中心接收到具有同一个事务ID的确 定了提交的事务日志(步骤S113:"是")，或者对于同一个事务， 在自身服务器中心中应答了"提交明白"(步骤S114:"是")，则应 答回退后结束(步骤S112)。
3) 如果不具有有效的处理权限Token (步骤S115:"否")， 则应答回退后结束(步骤S112)。
4) 在没有再次发送事务日志的情况下(步骤S116:"否")， 与事务ID、事务日志的LSN—起把事务日志加入到发送消息中(步 骤S117)。
5) 如果处理权限Token的有效期限小于等于一定时间(步骤 S118:"是")，则进行下述的处理(步骤S119)。
(a) 记录当前时刻。
(b) 决定有效期间。
(c )包括有效期间和处理权限Token的TSN在内，把处理权限 Token继续请求加入到发送消息中。
6) 把发送消息向其它的服务器中心发送(步骤S119a)。 <对提交请求的应答消息接收处理120 >
本处理由图6的提交请求应答接收单元65进行。以下，参照图 12的流程图详细说明。
1) 如果在返送消息中包括"继续明白"(步骤S121:"是，，)， 则把在上述步骤S119中记录的时刻上加上了处理权限Token的有效 期限得到的时刻作为有效期限进行记录(步骤S122)。
2) 如果从一个以上的服务器中心接收到"提交明白"的应答(步 骤123:"是")，则作为提交成功，记录其事务日志和其LSN后结 束(步骤S124)。
3) 如果从一个以上的服务器中心接收到提交拒绝的应答(步骤 S125:"是")，则作为回退，把其事务日志的LSN作为回退进行 记录后结束(步骤S128)。
4) 在即使等待某一定期间也没能接收到来自某个服务器中心的应答的情况下(步骤S126:"否")，则判断是否应该再次发送，如 果是应该再次发送(步骤S127:"是")，则在经过一定时间以后， 从步骤Slll起再次执行。否则的情况下，作为回退，把其事务日志 的LSN作为回退进行记录后结束(步骤S128)。
以下表示在接收到提交处理请求的服务器中心中的处理。
<提交请求消息接收处理130 >
本处理由图6的提交请求处理单元66进行。以下参照图13的流 程图详细说明。
1) 如果在自身服务器中心中已经进行具有同一个事务ID的事 务的提交处理(步骤S131:"是")，则返送提交拒绝并结束(步骤 S132)。
2) 如果从其它的服务器中心已经接收具有同一个事务ID的事 务日志，并且对于该日志应答了"提交明白，，(步骤S133:"是")， 则返送提交拒绝并结束(步骤S132)。
3) 如果自身服务器中心正在进行处理权限Token取得处理(步 骤S134:"是")，则返送再次发送委托后结束(步骤S135)。
4) 在接收到的消息内的处理权限Token的TSN比自身服务器 中心中记录的处理权限Token的TSN小的情况下(步骤S136:"是")， 把在自身服务器中心的记录中的当前的处理权限Token保持服务器 中心和其TSN包含在应答消息中，将提交拒绝返送后结束(步骤 S137)。
5) 在所接收到的消息内的处理权限Token的TSN比自身服务 器中心中记录的当前的处理权限Token的TSN大的情况下(步骤 S138:"是")，把在当前时刻上加上了处于接收到的消息内的处理 权限Token的有效期间的时刻作为有效期限，把处理权限Token保 持服务器中心作为消息的发送源服务器中心来进行记录(步骤S139 )。
6) 如果其它的服务器中心没有保持处理权限Token(步骤S140: "是")，则进行以下的处理。
(a )把在当前时刻上加上了提供给处理权限Token继续请求的有效期间的时刻记录为处理权限Token的有效期限(步骤S141)。 (b)把"继续明白"包含在返送消息中(步骤S142)。 7)把接收到的事务ID及其事务日志作为"提交明白"来记录，
返送"提交明白"(步骤S143， S144)。
在本发明中，从客户端来看，即使一个服务器中心发生了故障， 在不知道该故障的程度的时间内必须应答事务处理的结果。这里，所 谓r从客户端来看，不知道服务器中心的故障的程度的时间」是按照
应用的规格确定的正常时的最大应答时间。例如，是3秒左右的时间。 为了保证这一点，需要适当地设定事务处理的暂停时间、处理权限 Token的有效期间和客户端的直到再次发送为止的等待时间。以下表 示其一个例子。现在，如果设客户端的事务处理的最大等待时间为T，处理权限 Token的有效期间为Tt。，事务处理的暂停时间为Ttx，客户端的直到 再次发送为止的等待时间为Tew，则下面的式子成立。 T^max (Tcw， Tt0) + Ttx (式1)
Tcw>Ttx (式2) Tt0 > Ttx (式3 )
进而，当由客户端进行再次发送，向不是最初的服务器中心传送 时，为了用尽最初的处理权限Token的有效期限，使得接受了再次发 送请求的服务器中心能够获得处理权限Token,添加下述的公式。 Tcw > Tt0 (式4 )
只要确定Ttx、 Tew, Tt。，使得满足该(式l)、(式2)、(式 3)、(式4)即可。其中，(式4)不是必须的。
例如，如果设T为3000msec，则能够把U殳定为1400 msec, 把U殳定为1500 msec,把T^设定为1600 msec。
有效期间设定机构既可以使管理者经由专用画面输入这样的时 间值，也可以以所提供的T为基准计算并显示满足上述式子的值，进 而由管理者进行调整。所决定的时间值在各个服务器中心中发送并共用。
以上，使用实施形态以及实施例说明了本发明，但是本发明的技 术范围并不限于上述实施形态中记载的范围。能够在上述实施形态上 添加多种变更或者改良。另外，从权利要求范围的记载明确了添加了 这种变更或者改良的形态也包含在本发明的技术范围内。
作为本发明的一个实施形态所说明的事务处理方法能够由计算 机上的系统或者使其计算机执行其功能的程序来实现。另外，保存上 述程序的计算机可读取的记录介质能够是电子的、磁的、光学的、电 磁的、红外线或半导体系统(或者，装置或设备)或者传输介质。在 计算机可读取的记录介质的例子中，包括半导体或者固态存储装置、 磁带，在可装卸的计算机可读取的介质的例子中，包括半导体或者固
态存储装置、磁带、可装卸的计算机软盘、随机访问存储器(RAM)、 只读存储器(ROM)、硬磁盘以及光盘。在当前的光盘的例子包括 密致盘-只读存储器(CD-ROM)、密致盘-读/写(CD-R/W) 以及DVD。
权利要求
1.一种事务处理方法，是在由连接到网络上的多个客户端和多个服务器中心构成的计算机系统中的事务处理方法，其特征在于，上述服务器中心至少由一个数据库、管理该数据库的DB服务器、以及与上述DB服务器和上述客户端交互通信的一个以上的应用服务器构成，上述事务处理方法包括根据从上述客户端经由上述应用服务器的事务开始请求，参照该事务的ID，判断同一ID的事务是否已经正在执行或已经完成提交，如果上述同一ID的事务正在执行或者已经完成提交，则对于该事务开始请求应答回退的步骤；确认自身服务器中心是否保持着有效的处理权限Token，如果没有保持上述处理权限Token，则向上述自身服务器中心以外的其它所有的服务器中心发行上述处理权限Token的取得请求，等待从过半数的服务器中心完成该取得请求的步骤；在取得上述处理权限Token时，上述自身服务器中心在上述其它所有的服务器中心之间进行数据匹配的步骤。
2. 根据权利要求l所述的事务处理方法，其特征在于， 上述事务处理方法还包括向所有的上述服务器中心传送对象事务的上述事务ID、该事务 更新的数据、向该事务的请求源返送的处理结果，确认至少在过半数 的服务器中心中的上述数据库中拷贝了上述数据的步骤；在上述进行确认的步骤中确认成功了的情况下，向上述其它所有 的服务器中心发送提交请求的消息，在接收到来自过半数的服务器中 心的提交合意的情况下，判断为上述提交请求成功的步骤；向上述其它所有的服务器中心发送上述进行判断的步骤所确定 的提交的结果的步骤。
3. 根据权利要求2所述的事务处理方法，其特征在于，还包括在上述处理权限Token的取得处理中接收到上述提交请求的情 况下，直到上述处理权限Token的取得处理完成为止，不进行对该提 交请求的回信，或者进述提交请求的消息的再次发送委托的步 骤。
4. 根据权利要求2所述的事务处理方法，其特征在于，还包括 在向上述其它所有的服务器中心发送上述提交请求的消息、接收其应答而确定提交之前的期间中，当接收到上述处理权限Token的取 得消息时，直到该提交确定为止，不进行对上述处理权限Token的取 得消息的回信，或者进行上述处理权限Token的取得消息的再次发送 委托的步骤。
5. 根据权利要求l所述事务处理方法，其特征在于，还包括 在上述处理权限Token的取得完成之前，从其它的上述服务器中心接收未确定的事务日志，使上述未确定的事务日志的状态同步的 步骤。
6. 根据权利要求2所述的事务处理方法，其特征在于，还包括 在接收上述处理权限Token的取得请求消息以及接收该处理权限Token的取得请求应答消息时，在上述消息中包括提交不明确的事 务信息的情况下，参照上述事务信息，在该事务的提交或者回退已经 确定的情况下，返送其结果的步骤。
7. 根据权利要求2所述的事务处理方法，其特征在于，还包括 对上述提交请求的消息，判断该提交请求的消息的发送源以外是否保持着有效的上述处理权限Token,如果是保持着则对提交请求应 答拒绝，如果没有保持则应答承认的步骤。
8. 根据权利要求l所述的事务处理方法，其特征在于，还包括 把发送上述事务开始请求的客户端的事务再次发送时间和上述处理权限Token的有效期间设定在上述客户端中的步骤。
9. 根据权利要求l所述的事务处理方法，其特征在于， 上述处理权限Token是包括了有效期限的带时间限制的Token。
10. —种事务处理系统，该事务处理系统由连接到网络上的多个客户端和多个服务器中心构成，其特征在于，上述服务器中心至少由一个数据库、管理该数据库的DB服务 器、以及与上述DB服务器交互通信的一个以上的应用服务器构成， 上述事务处理系统具备事务重复检测单元，根据从上述客户端经由上述应用服务器的事 务开始请求，参照该事务的ID，判断同一ID的事务是否已经正在执 行或已经完成提交，如果上述同一 ID的事务正在执行或者已经完成 提交，则对该事务开始请求应答回退；Token排斥控制单元，确认自身服务器中心是否保持着有效的处 理权限Token,如果没有保持上述处理权限Token,则向上述自身服 务器中心以外的其它所有的服务器中心发行上述处理权限Token的 取得请求，等待从过半数的服务器中心完成该取得请求；数据匹配处理单元，在取得上述处理权限Token时，上述自身 服务器中心在所有的上述服务器中心之间进行数据匹配，进而，上述事务处理系统在上述事务的提交处理中，具备数据复制处理单元，向上述其它所有的服务器中心传送对象事务 的上述事务ID、该事务更新的数据、向该事务的请求源返送的处理结 果，确认至少在过半数的服务器中心中的上述数据库中拷贝了上述数 据；提交确定处理单元，在由上述数据复制处理单元进行的确认成功 了的情况下，向上述其它所有的服务器中心发送提交请求的消息，在 接收到来自过半数的服务器中心的提交合意的情况下，判断为上述提 交请求成功；提交发送单元，向上述其它所有的服务器中心发送上述提交确定 处理单元所确定的提交的结果。
11.根据权利要求10所述的事务处理系统，其特征在于，还具备把发送上述事务开始请求的客户端的事务再次发送时间和上述 处理权限Token的有效期间设定在客户端中的有效期间设定机构。
12. —种事务处理装置，是在由连接到网络上的多个客户端和多 个服务器中心构成的计算机系统中的事务处理装置，其特征在于，上述服务器中心至少由一个数据库、管理该数据库的DB服务 器、以及一个以上的应用服务器构成，上述事务处理装置包含在上述DB服务器中，并具备Token请求发送单元，根据来自上述客户端的经由上述应用服务 器的事务开始请求，为了使上述自身服务器中心得到访问上述数据库 的权限，发送处理权限Token取得请求消息；Token应答接收单元，接收针对上述处理权限Token取得请求 消息的应答消息；提交请求发送单元，发送提交请求消息；提交应答接收单元，接收对上述提交请求消息的应答消息，其中，上述Token请求发送单元在上述自身服务器中心没有保 持处理权限Token的情况下，向上述自身服务器中心以外的其它所有 的服务器中心发送处理权限Token取得请求消息，上述Token应答接收单元根据从针对上述处理权限Token取得 请求消息的过半数的服务器中心接收到应答，判断处理权限Token的 取得成功、取得失败，上述提交请求发送单元在上述处理权限Token的取得成功了的 情况下，向上述其它所有的服务器中心发送包括事务日志的提交请求 消息，上述提交应答接收单元在从过半数的服务器中心接收到"明白" 消息的情况下，判断为提交成功。
13. 根据权利要求12所述的事务处理装置，其特征在于， 上述处理权限Token是包括了有效期限的带时间限制的Token。
14. 根据权利要求12所述的事务处理装置，其特征在于，还具备把发送上述事务开始请求的客户端的事务再次发送时间和上述 处理权限Token的有效期间设定在上述客户端中的有效期间设定机构。
15. —种计算机程序，是由连接到网络上的多个客户端和多个服 务器中心构成的计算机系统中的计算机程序，其特征在于，上述服务器中心至少由一个数据库、管理该数据库的DB服务 器、以及与上述DB服务器和上述客户端交互通信的一个以上的应用 服务器构成，上述计算机程序使计算机系统执行如下步骤根据从上述客户端经由上述应用服务器的事务开始请求，参照该 事务的ID,判断同一ID的事务是否已经正在执行或已经完成提交， 如果上述同一ID的事务正在执行或者已经完成提交，则对于该事务 开始请求应答回退的步骤；确认自身服务器中心是否保持着有效的处理权限Token,如果没 有保持上述处理权限Token,则向上述自身服务器中心以外的其它所 有的服务器中心发行上述处理权限Token的取得请求，等待从过半数 的服务器中心完成该取得请求的步骤；在取得上述处理权限Token时，上述自身服务器中心在所有的 上述服务器中心之间进行数据匹配的步骤。
16. 根据权利要求15所述的计算机程序，其特征在于， 上述计算机程序还使计算机系统执行如下步骤 向所有的上述服务器中心传送对象事务的上述事务ID、该事务更新的数据、向该事务的请求源返送的处理结果，确认至少在过半数 的服务器中心中的上述数据库中拷贝了上述数据的步骤；在上述进行确认的步骤中确认成功的情况下，向上述其它所有的 服务器中心发送提交请求的消息，在接收到来自过半数的服务器中心 的提交合意的情况下，判断为上述提交请求成功的步骤；向上述其它所有的服务器中心发送上述进行判断的步骤所确定 的提交的结果的步骤。
17. 根据权利要求15或权利要求16所述的计算机程序，其特征在于，还使计算机系统执行将发送上述事务开始请求的客户端的事务再次发送时间和上述处理权限Token的有效期间设定在上述客户端 中的步骤。
18. 根据权利要求15或17所述的计算机程序，其特征在于， 上述处理权限Token是包括了有效期限的带时间限制的Token。
19. 一种记录介质，其特征在于， 记录了权利要求14至权利要求18记栽的计算机程序。
全文摘要
本发明提供一种不间断事务处理系统。在业务系统中，使由服务器或者网络等故障引起的服务暂时中断的时间缩短变为重要，当前的故障应对一般利用故障检测和移交的方式，而由于在故障检测中至少需要10秒到几分钟的时间，因此服务中断时间在其以上，成为重大的问题。本发明提出了不等待故障检测，在一定时间没有应答的情况下，从客户端向备用的服务器中心再次发送处理的系统。本发明的事务处理机构具备把使用了处理权限Token的排斥控制与数据匹配相组合的事务开始处理机构、把基于分散合意的能否提交判断与更新数据的复制相组合的提交处理机构。依据该机构提供在故障发生时把服务停止时间缩短到从客户端来看服务没有停止的程度的时间的系统。
文档编号G06F9/46GK101317163SQ200680044766
公开日2008年12月3日 申请日期2006年11月30日 优先权日2005年11月30日
发明者堀井洋, 山本学, 田井秀树 申请人:国际商业机器公司