CN101853186A - 分布式事务恢复系统和方法 - Google Patents

分布式事务恢复系统和方法 Download PDF

Info

Publication number
CN101853186A
CN101853186A CN200910266025A CN200910266025A CN101853186A CN 101853186 A CN101853186 A CN 101853186A CN 200910266025 A CN200910266025 A CN 200910266025A CN 200910266025 A CN200910266025 A CN 200910266025A CN 101853186 A CN101853186 A CN 101853186A
Authority
CN
China
Prior art keywords
affairs
transaction
application server
transaction journal
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN200910266025A
Other languages
English (en)
Inventor
拉尔夫·库希
彼得·H·佩谢夫
尼古莱·D·坦科夫
托马斯·H·沃尔特
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAP SE
Original Assignee
SAP SE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SAP SE filed Critical SAP SE
Publication of CN101853186A publication Critical patent/CN101853186A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2033—Failover techniques switching over of hardware resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1474—Saving, restoring, recovering or retrying in transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2025—Failover techniques using centralised failover control functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

在一个实施例中，本发明包括一种用于分布式计算环境中的事务恢复的系统。该系统包括：事务日志服务器、应用服务器和资源服务器。事务日志服务器存储共享事务日志。应用服务器实现分布式事务应用，并且在使用分布式事务应用执行事务时，访问共享事务日志。资源服务器存储数据，并根据事务与多个应用服务器操作以访问数据。如果所述多个应用服务器之一出现故障，则另一应用服务器承担之前由故障应用服务器访问的共享事务日志的部分的责任。

Description

分布式事务恢复系统和方法
技术领域
本发明涉及事务可恢复性(transactional recoverability)，具体地，涉及分布式计算环境中的事务可恢复性。
背景技术
除非在此另外指示，否则在本部分中描述的方法不是本申请权利要求的现有技术，并且不因包括在本部分中而承认其为现有技术。
在目前的许多商业企业中，企业应用正借助企业内部或外部存在的许多分布式资源。这些资源可以是数据库、消息传递系统或者甚至可以是向外部世界提供服务的应用。
在许多情况下，期望以事务的方式进行遍及这种系统的更新。这基本意味着所述更新必须符合ACID准则(原子性(atomicity)、一致性、隔离性和持续性)。原子性意味着分布式资源中的改变在所有资源都执行或都不执行。一致性意味着当事务结束时，在这些资源之间的完整性约束必须有效。隔离性意味着事务外部的任何操作都看不到中间状态。持续性意味着如果事务成功结束，则它将持续并且不被撤销。
目前，在企业内常见的几乎所有资源都符合这些准则。如果要求数据库管理系统(DBMS)在单个事务(transaction)中从一个账户取钱并且存入另一账户，那么可以预期该DBMS能够根据上述ACID规则完美地完成这一事务。该DBMS本身对该事务进行完全地控制，它既是事务管理器，也是被事务管理器管理的资源。
如果事务必须跨越多个资源，则情况完全改变。应用服务器变为事务管理器，而所有资源变为该事务管理器的下级(subordinate)。因为事务的整体状态现在分布在所有涉及到的资源管理器上，所以将存在一些时间量，在所述时间量期间整个事务不一致。
所述不一致性不是可以避免的事情，它存在于分布式系统的基本性质中。因此如果执行事务工作或其部分的系统崩溃，则该不一致性将持续。这种情况的一个例子可以是，在一个资源已经进行了它的改变而第二个资源还没有进行改变时，应用服务器崩溃。
为了克服这些问题，可以使用事务恢复(transaction recovery)策略。如果在事务中涉及的系统再次变为可用，则应用服务器中的事务恢复功能会记起向触发该事务的应用承诺过什么。应用服务器与资源检查它们那部分事务的结果，并试图达到一致状态。如果应用服务器不能达到一致状态，则它将所涉及的资源之间的这种不一致性通知给操作者，从而至少标识出问题。
如果在没有事务可恢复功能的情况下使用分布式事务，则客户数据极有可能会被损坏。这就是利用当前的JavaTM应用服务器架构的情况。如在JavaTransaction Processing(Java事务处理)一书中所描述的：“一些应用服务器(目前这主要应用于实验性项目或开源项目，而没有应用于企业级质量服务器)不提供恢复能力，这些应用服务器不应当用于与要求事务的多个可恢复资源交互的应用”。见Mark Little等人的Java Transaction Processing(PrenticeHall PTR 2004)。
实现事务恢复是对应用服务器的根本改变。可以创建并使用新的恢复功能。此外，可以改变实现资源的方式。这可能需要对其他系统进行进一步地修改，所述其它系统例如服务器内的JavaTM消息传递系统提供者(JavaTMMessaging System(JMS)provider)、事务管理器(Transaction Manager，TM)、JDBC(JavaTM Database Connectivity，JavaTM数据库连接)DB(数据库)池服务、以及Java连接器容器(Java Connector Container)。
如果应用服务器和事务管理器(其曾是应用服务器的一部分)一起崩溃，则在事务中曾涉及的资源被单独留下。这种单独的资源是危险的，因为仍然存在未决的(pending)事务：在一段时间后，该资源将会决定是提交(commit)还是回滚(rollback)它所涉及的事务部分。这一决定可能符合也可能不符合事务管理器的原始意图——这就是所谓的启发式决定(heuristic decision)。因此，只要可能就必须避免启发式决定。
分布式计算环境通常包括多个层，其中每层具有一个或多个计算设备。例如，两层架构可以包括客户端层和服务器层，在每层中具有多个客户端设备和多个服务器设备。三层架构可以包括客户端层、应用服务器层和数据库服务器层(同样，在每层中具有多个计算设备)。
应用服务器层也可以被称为应用服务器集群(application server cluster)。应用服务器集群可以由许多服务器节点组成，这些服务器节点可以遍及分布式资源执行事务。应用服务器可以实现诸如JavaTM企业版(JavaTM EnterpriseEdition)、Microsoft.NETTM环境等的计算环境。
数据库服务器层也可以称为资源层。存在于应用服务器上的应用可以以事务的方式(transactional manner)使用(资源层的)不同资源。资源的例子有数据库系统、消息传递系统和企业信息系统。
应用服务器中控制事务的部分被称为事务管理器(TM)。TM用来安排(orchestrate)遍及这些分布式资源的事务的语义学(semantics)可以通过来自国际标准化组织Open Group的DTP(Distributed Transaction Processing，分布式事务处理)XA规范来描述。
TM代表存在于服务器上的应用管理事务。这意味着它负责将所有资源保持在一致状态。由于事务的整体状态分布在所有涉及的资源管理器上，所以将存在一些时间量，在所述时间量期间整个事务不一致。
所述不一致性是不可避免的——它存在于分布式系统的基本性质中。因此如果执行事务工作(或其部分)的系统崩溃，则该不一致性将持续。这种情况的一个例子是，在一个资源已经进行了它的改变而第二个资源还没有时，应用服务器节点崩溃。如果一个或多个应用服务器节点崩溃，则分布式事务可能保持在未完成状态。
由于这种事务的每一个参与者都可能崩溃，因此每一个参与者有必要将其提交或回滚的决定写到持久存储器(persistent store)中。该存储器被称为事务日志(Transaction Log，TLOG)。
可以根据Open Group的DTP XA规范进行事务处理。该规范将事务的完成划分为两个阶段：准备阶段和提交阶段。
下面描述具有两个参与者的事务完成过程。资源1利用资源适配器1连接到应用服务器，资源2利用资源适配器2连接到应用服务器。每个参与者都具有它自己的TLOG。因此，总共存在三个TLOG：一个由TM维护，另两个由它们各自的资源管理器控制。
事务完成过程如下：
1.应用要求应用服务器提交事务。
2.应用服务器通知TM应当完成的事务。
3.TM启动事务完成的第一阶段：它要求第一资源管理(RM)准备事务。
4.假设第一RM能够提交并且将该意图写到它自己的事务日志中。该第一RM从准备调用(prepare call)返回，用信令通知TM成功。
5.对第二RM执行同样的过程。
6.由于我们假设TM只接收到成功的准备返回代码，因此它决定提交全部事务。TM在其联系RM之前将其提交的决定写入它自己的TLOG。在写操作后，TM将试图提交该事务，即使该TM在写操作后立即崩溃也是如此。
7.第一RM被要求提交。通常，第一RM应当履行它在准备时间期间向TM做出的承诺，并且没有任何问题地提交。
8.第二RM被要求提交。
在进行任何准备调用之前的问题都不严重。在一段时间后，每个参与者都将放弃该事务，最终再次达到一致状态。
较为严重的是准备之后的问题。例子可以是，在步骤7之后步骤8之前应用服务器崩溃。这将导致资源管理器1已经提交了其事务分支，而资源管理器2仍然停留在准备状态中。
如果这种情况持续，则资源管理器2将(在一段时间后)自己决定其事务分支的结果。它将做出启发式决定(heuristic decision)。许多现有的资源管理器都将决定回滚它们的分支。如果这种情况发生，则整个事务将不一致。DTP XA规范将这称为“启发式混合事务结果”(heuristic mixed transactionoutcome)。
此外，完成过程可能要花费一段时间，特别是如果资源管理器较慢时更是如此。想象较慢的RM 1：如果在2PC(2阶段提交)协议的第二阶段期间发生故障，则整个事务不一致。在应用服务器的许多当前实现中，该不一致性将被忽视，因此客户数据损坏的可能性非常高。
然后，现有的应用服务器会尝试使用恢复服务来恢复这些分布式事务。
发明内容
本发明的各实施例改进了分布式计算环境中的事务恢复。在一个实施例中，本发明包括一种用于分布式计算环境中的事务恢复的系统。该系统包括：事务日志服务器、应用服务器和资源服务器。事务日志服务器存储共享事务日志。应用服务器实现分布式事务应用，并且在使用分布式事务应用执行事务时访问共享事务日志。资源服务器存储数据，并根据事务与应用服务器操作来访问数据。如果应用服务器之一出现故障，则另一应用服务器承担之前由故障应用服务器访问的共享事务日志的部分的责任。
根据实施例，一种计算机程序控制分布式计算环境中的事务恢复。该计算机程序控制事务日志服务器、应用服务器和资源服务器，使它们如上所述工作。
根据实施例，一种方法控制分布式计算环境中的事务恢复。该方法控制事务日志服务器、应用服务器和资源服务器，使它们如上所述工作。
下面的详细描述和附图提供对本发明的本质和优点的更好理解。
附图说明
图1是根据本发明实施例的分布式计算环境的方框图。
图2是示出图1的分布式计算环境的一些组件的更多细节的方框图。
图3是示出根据本发明实施例的两个应用服务器和事务日志服务器的更多细节的方框图。
图4是根据本发明实施例的分布式计算环境中的事务恢复方法的流程图。
图5是根据本发明实施例图示在所有资源管理器已经成功进行了准备时的时间点的活动图的流程图。
图6是根据本发明实施例的概述事务管理器如何处理返回代码的活动图的流程图。
图7A-7D图示了根据本发明实施例的四种使用情况。
图8是用于实现本发明实施例的示例计算机系统和网络的方框图。
具体实施方式
在此描述的是用于事务恢复的技术。在下面的描述中，出于说明的目的，阐述了许多示例和特定细节，以便提供对本发明的全面理解。然而，对本领域技术人员明显的是，由权利要求定义的本发明可以单独包括或者与下面描述的其他特征组合地包括这些示例中的一些或全部特征，并且还可以包括在此描述的特征和概念的修改和等效方式。
本发明的实施例没有使用单个恢复服务(single recovery service)方法。取而代之，可以适当地存在多个恢复服务，该多个恢复服务可以并行地恢复未决事务。为了避免这些恢复服务之间的冲突，可以将事务日志划分为若干逻辑部分，其中每个部分最多可以被一个恢复服务使用。
这会带来更快的恢复(存在于具有最少负载的节点上的恢复服务将赢得对孤立事务日志(orphaned transaction log)的竞争)和更高的吞吐量(如果存在若干孤立事务日志，则它们将被不同节点上的不同恢复服务并行处理)。
本发明的实施例定义了这样的架构，其中任何存活的(surviving)应用服务器节点都可以立即恢复这些未决事务，而不用使集群中的一个成员专门用作单个恢复节点。
每个应用服务器节点在每次启动时创建新的(逻辑)事务日志。如果该节点崩溃，则存在于存活节点上的恢复服务竞争孤立的事务日志，并且恢复其中包含的事务。
因此，可以适当地并行存在若干恢复服务，它们能够并行恢复事务。
本发明的实施例可以具有一个或多个以下特征。一个特征是，如果应用服务器节点崩溃，则事务的恢复可以快速发生。这有助于避免将增加启发式资源管理器决定的风险的任何延迟。这是在另一存活应用服务器节点上执行恢复而不等待崩溃节点重启所带来的结果。另一特征是，如果资源管理器暂时不能执行事务处理(可能由于网络中断或资源管理器崩溃)，则事务管理器可以连续地试图联系该资源管理器以尽快解决任何未决的事务分支。根据本发明的实施例，可以通过可称为未决事务列表(PTL)处理器的同一个应用服务器解决两个任务——立即恢复和解决未决事务。在详细描述PTL处理器的操作之前，提供一些背景。
图1是根据本发明实施例的分布式计算环境100的方框图。分布式计算环境100具有三层：客户端层102、应用层104和数据库层106。在替代实施例中可以存在更多或更少的层；示出三层是因为它们提供了便于讨论的一般情况。
网络1 08连接各层以及特定层内的计算设备。网络1 08被显示为两个参照块；在给出三层的情况下这种表示是出于图示的目的。要理解的是，网络108可以包括子网络(例如，第一局域网、第二局域网、因特网等)，或者可以连接到其他网络(未示出)。
客户端层102包括一个或多个客户端计算机112。示出了三个客户端计算机112a、112b和112c。通常，客户端计算机112提供用户接口，并增强用户与分布式计算环境100交互的能力。
应用层104包括一个或多个应用服务器114。示出了三个应用服务器114a、114b和114c。通常，应用服务器114执行应用程序，所述应用程序与数据库层106交互以进行数据访问，并且与客户端层102交互以进行数据表示。
数据库层106包括一个或多个资源服务器116。示出了三个资源服务器116：数据库服务器116a、消息传递服务器116b和企业信息服务器116c。通常，资源服务器116管理由应用服务器114访问的数据。
根据实施例，分布式计算环境100按照JavaTM企业版环境操作。例如，客户端计算机112可以实现网页浏览器，其与应用服务器114交换JavaTM格式的信息。应用服务器114可以产生由资源服务器116执行的SQL(结构化查询语言)语句。
事务日志服务器120维护共享事务日志，在下面将更详细地讨论。
图2是示出分布式计算环境100的一些组件的更多细节的方框图。示出的是应用服务器114d、资源服务器116a和116b、网络108a和事务日志服务器120a。(图2的组件对应于图1中的具有类似标记的组件。)
作为示例，应用服务器114d可以实现股票交易计算机程序。资源服务器116d存储与用户的经纪账户对应的数据，并且资源服务器116e存储与用户的银行账户对应的数据。
事务日志服务器120a存储共享事务日志130。根据实施例，事务日志服务器102a是数据库服务器，并且共享事务日志130是由数据库服务器(例如，数据库管理系统或DBMS)存储的数据库中的数据结构。根据实施例，事务日志服务器102a是文件系统服务器，并且共享事务日志130是由文件系统服务器存储的数据文件。文件系统服务器可以是存储设备，如NAS(网络附加存储)设备或SAN(存储区域网络)设备。共享事务日志130还可以称为TLOG130。
应用服务器114d包含事务管理器132和PTL处理器134。事务管理器132管理由应用服务器114d执行的事务。例如，参照上面讨论的经纪示例，事务管理器132管理执行股票购买事务的步骤，例如：与银行账户服务器通信以锁定购买量；与经纪服务器通信以锁定要购买的股票数量；与锁定了股票购买的银行账户服务器通信，以使该银行账户服务器能够将钱从购买者的账户移动到经纪人的账户；并且与钱被移动的经纪服务器通信，使得经纪服务器能够将股票从经纪人的账户移到购买者的账户。
PTL处理器134(也称为恢复服务)以分散的方式组合两种能力。一种能力是恢复从应用服务器114d上一次启动时起在应用服务器114d(其中实现了PTL处理器134)上创建的未决事务。另一种能力是恢复已经崩溃的其他应用服务器114遗留的未决事务。
在每个应用服务器114上实现一个PTL处理器134。不需要使一个PTL处理器134不同于其他PTL处理器；例如，不需要为整个环境工作的单例(singleton)PTL处理器。
作为示例，假设应用层104中的节点的集群(例如，见图1中的应用服务器114)由已启动的节点“a、b、c、d”组成。假设每个节点都具有未决的事务。因为这被定义为所有节点的第一次启动，所以每个节点的每个PTL处理器只关注源自每个PTL处理器实现于其上的节点的事务。
缩写“a:a(1)”代表“节点a”试图解决在节点“a”的运行次数“1”期间产生的未决事务的情况。因此，所述情况为“a:a(1)、b:b(1)、c:c(1)、d:d(1)”。
假设节点a崩溃并且具有一些未决事务。任何剩余节点都能够接管这些事务。我们假设节点b是最快的。因此，现在情况为“b:b(1)+a(1)、c:c(1)、d:d(1)”。
现在假设节点b崩溃。同样，节点c和节点d竞争。可能并且非常有可能节点c和节点d将仅仅部分地接管节点b曾试图解决的未决事务。一个可能的结果是，“c:c(1)+b(1)、d:d(1)+a(1)”。
如果节点a再次出现，则节点a不需要关心来自它较早的运行的事务。这是因为很可能某个其他节点已经关照了那些事务。因此，情况将是“a:a(2)、c:c(1)+b(1)、d:d(1)+a(1)”。
结果，TLOG可以在逻辑上被分段为不同的部分，这些不同的部分可以具有不同的拥有者。因为我们允许将文件系统或DBMS用作用于TLOG的底层持久层(underlying persistence layer)，所以这可以通过两种选项来实现。一种选项是基于文件系统的TLOG。节点的每次启动创建新的物理文件。该文件系统可以在各节点之间共享，以使得节点可以接管另一节点的TLOG。另一选项是基于DBMS的TLOG。对于所有节点可以只存在一组共享表。数据库方案允许DBMS区分来自不同节点以及不同节点启动的各个条目。
图3是示出根据本发明实施例的两个应用服务器114e和114f以及事务日志服务器120b的更多细节的方框图。应用服务器114e包括节点m 302a、事务管理器132a、PTL处理器控制器304a、夺取(grab)TL标志306a、未决事务(TX)列表308a、和PTL处理器134a。应用服务器114f包括节点m+1 302b、事务管理器132b、PTL处理器控制器304b、夺取TL标志306b、未决事务列表308b、和PTL处理器134b。节点302a和302b可以看作是应用计算机程序的实例。
事务日志服务器120b包括六个事务日志320a、320b、320c、322a、322b和322c。事务日志320a、320b、320c、322a、322b和322c被示为分开的逻辑实体。逻辑事务日志320a、320b、320c、322a、322b和322c也可以通过事务日志服务器120b在物理上存储为单个物理数据结构，如文件或数据库结构。事务日志320a、320b和320c与应用服务器114e相关联，而事务日志322a、322b和322c与应用服务器114f相关联。
如图3所示，我们假设两个应用服务器节点302a和302b(m和m+1)存在于不同的物理机箱上(应用服务器114e和114f)。通过事务管理器132a和132b进行事务处理。PTL处理器304a和304b分别是TM 132a和132b的一部分，但是每个在其自己的线程中运行。
一个有关PTL处理器134a的值得注意的数据结构是未决事务列表(PTL)308a。未决事务列表308a可以是存储器内(in-memory)的结构。未决事务列表308a包含需要解决的事务的列表。
为了资源优化，如果在PTL 308a中不存在条目，则PTL处理器134a可以停止。这在图3中示出，其中PTL处理器134a正在PTL处理器控制器304a内运行，该PTL处理器控制器304a控制PTL处理器134a的生命周期。
存在两种可以导致添加PTL条目的方式：
1.如果TM 132a遇到有问题的事务(例如，在2PC提交协议的第二阶段期间有故障的事务)，则它将该事务添加到PTL 308a，并且继续服务应用请求。
2.如果集群节点之一302b崩溃，则集群基础架构将所有其他集群节点的“夺取事务日志(TL)”标志设置为真。(例如，在只显示一个其他节点302a的情况下，为夺取TL标志306a)。这指令所有其他PTL处理器(例如，在只显示一个其他节点302a的情况下，为PTL处理器134a)开始这样的周期，在所述周期中所述所有其他PTL处理器试图获得对孤立事务日志的独占访问，并且将所述孤立事务日志的内容复制到它们各自的PTL(同样，在只有一个其他节点的情况下，为PTL 308a)中。
事务日志130(见图1)由不同的逻辑事务日志实体(例如，320a、320b、320c、322a、322b和322c)构成。一个逻辑TLog(例如，320a)可以只具有一个PTL处理器(例如，134a)或TM(例如，132a)作为拥有者。在图3中，图示了下面的情况：
·节点m 302a的TM 132a写入在该节点m 302a上一次启动时创建的TLog n 320a。标记“n”可以称为运行标识符。
·节点m 302a的PTL处理器134a正在解决来自该节点的上一次运行和之前两次运行的事务。这显示为对节点m 302a的TLog n-1 320b和n-2 320c的读/写访问。
·节点m 302a的PTL处理器134a正在解决来自节点m+1 302b的上一次运行的事务。这示为指向节点m+1 302b的TLog n-1 322b的读/写访问箭头。
·节点m+1 302b的TM 132b写入在上一次启动时新创建的节点m+1302b的TLog n 322a。
·节点m+1 302b的PTL处理器134b当前解决来自上一次运行之前的运行的事务。这示为指向节点m+1 302b的TLog n-2 322c的箭头。
如果解决了特定逻辑事务日志(例如，320c)的所有事务，则通过PTL处理器(例如，134a)将其移除(remove)。可以存在可配置的超时(time-out)，在该超时之后放弃(abandon)不可恢复的事务(典型地如一天)。因此，在一段时间后，旧的TLog(例如，320c)将消失。
图4是根据本发明实施例的分布式计算环境中的事务恢复方法400的流程图。方法400可以通过分布式计算环境100(见图1)实现。
在步骤402，存储共享事务日志。
在步骤404，当使用分布式事务应用执行事务时，访问共享事务日志。该分布式事务应用通过多个应用服务器实现。
在步骤406，根据事务访问数据。可以按照2PC(2阶段提交)过程执行该数据访问。
在步骤408，如果应用服务器之一发生故障，则另一个应用服务器(称为有效(active)应用服务器)承担之前由该故障应用服务器访问的共享事务日志的部分的责任。因为只有一个应用服务器可以对共享事务日志的特定部分负责，所以通常具有最低负载的应用服务器将最快地对故障作出响应，并且将变为有效应用服务器，接管故障应用服务器的事务日志条目的责任。
详细示例实施例
下面各部分提供关于上述结构和过程的更多细节。为了提供附加的细节的背景，可能存在一些重复。
1.概述
存在四个值得注意的组件，它们关注应用服务器中的事务及其恢复。这些组件包括事务管理器(TM)、事务日志(TLOG)、未决事务列表(PTL)和PTL处理器(PP)。(例如，见图3。)
事务管理器(例如，图3中的132a)可以实现为来自SAP AG的NetWeaverJava服务器的一部分。TM协调事务。根据实施例，TM是多线程的，这意味着事务总是在应用的线程中开始。如果TM决定提交事务，则它将用于该事务的条目写入持久事务日志(TLOG)。这在对任何所涉及的资源管理器(RM)执行任何提交调用之前发生。因此，TM记录它的提交的意图，而不是任何提交操作的结果。
如果在TLOG中不存在用于事务的条目，则意味着TM决定回滚(RB)该事务。根据实施例，这种更新TLOG的方式可以按照“假定终止”(Presumed-Abort)策略来执行。见Weikum和Vossum的TransactionInformation System(事务信息系统)，第19章，分布式事务恢复(Academic Press2002)。
一些错误状况使得TM不可能将两阶段提交事务立即带入一致状态。对于这些情况的详细描述，请阅读下面关于资源管理器错误的部分。在这种情况下，TM不再阻挡(block)应用线程，而是将事务移交到未决事务列表(PTL)。
TLOG(例如，图3中的320a)存储TM提交事务的决定。可以存储在系统DBMS或文件系统中。根据实施例，对于TM的每次启动，都会创建新的逻辑TLOG。在文件系统中，这可能导致许多物理TLOG。
根据实施例，PTL(例如，图3中的308a)是存储器内的结构。它包含由于一个或多个所涉及的RM有问题(例如，故障)所以目前不能被解决的事务。PTL中的条目可以意味着事务必须被提交，或者事务必须被回滚。另外，每个条目跟踪每个事务分支的状态——因此，总是清楚哪个RM返回了什么结果以及哪个RM直到现在仍不能被成功联系到。
PTL处理器(例如，图3中的134a)试图解决PTL中的事务。它通过针对PTL中的所有条目进行循环来试图解决PTL中的事务。PTL处理器和TM以相同的方式处理事务。这意味着稍后描述的所有RM错误处理对于TM和PP是完全相同的。唯一的差别是，PTL处理在它自己的线程中发生，而不是在应用请求的线程中发生。
PP还可能从外部事务日志读入事务。因此，PTL可以包含指向许多TLOG的条目。
2.事务管理器
事务管理器必须处理在2PC协议的不同阶段期间资源管理器(RM)可以提供的复杂的返回代码。在下述实施例中会增加额外的复杂度：在所述实施例中，实现XA资源接口的不同资源管理器可能对于在特定情况下应该选择哪个返回代码具有不同的解释。此外，围绕事务的不同规范有时候是模糊的或者不完整的。
为了解决该问题，在一个实施例中，如果遇到返回代码，该实施例将正式的开发组XA规范(Open Group XA Specification)实现为解释的源。这意味着(根据实施例)TM甚至会处理在JSR-000907 JavaTM事务API规范中没有提到、而仅仅在Open Group XA规范中提到的返回代码。即使这些返回代码在JavaTM文献中没有提到，我们预期它们也会在真实世界中发生，因为一些JavaTM资源管理器仅仅是围绕现有C/C++资源管理器实现的瘦JavaTM包装(thin JavaTMwrapper)。
2.1准备阶段之前的资源管理器错误
在准备阶段之前，错误处理不像准备之后那样复杂。可以预期，即使所有涉及的各方失去了相互联系，它们也可以回滚它们的事务部分，从而不一致性应当只存在相对短的时间。尽管如此，也需要密切关注在该阶段期间JTAXAResource(XA资源)接口的不同操作：
Operation：start(Xid xid，int flags)(操作：开始(Xid xid，int flags))
根据实施例，连接应当总是指向(pinned to)事务。因此，所使用的标志的唯一值是TMNOFLAGS。根据替代实施例，连接可以利用end(TMSUSPEND)和start(TMJOIN)来中止(suspend)和继续(resume)。这将导致使用较少的连接，但是可能具有负面的性能影响。附加的风险是，一些RM可能不能实现适当的事务中止机制。
Operation：end(Xid xid，int flags)(操作：结束(Xid xid，int flags))
根据实施例，只使用TMSUCCESS。根据替代实施例，如果TM决定回滚，则优化方式将是调用end(TMFAIL)。这将节约针对所涉及的RM的附加的回滚调用。由于不清楚是否所有的RM都支持这一优化方式，并且因为只有低比例的事务将被回滚，所以该替代实施例在一些实现中可能是不理想的。
如果返回代码是除XA_OK之外的任何代码，则全部事务将被回滚。(更精确地讲，在Java中除XA_OK之外的XA返回代码都被翻译为异常)。如果返回代码是XA_RB*，则全部事务将被回滚，而不是在返回该代码的RM处发出回滚调用。
Operation：prepare(Xid xid)(操作：准备(Xid，xid)
根据实施例，如果RM返回RDONLY，则立即将该RM从事务中排除。不将用于该分支的条目写入TLOG。RDONLY结果既不是提交的投票也不是回滚的投票。
如果返回XA_RB*，则事务将被回滚，但是将不会针对这些特定的RM调用回滚。它们投票赞成回滚并且已经执行了回滚。如果所有准备调用都成功，则TM决定提交事务。
Operation：commit(Xid xid，boolean onePhase)(操作：提交(Xid xid，boolean onePhase))
根据实施例，如果onePhase被设置为真，则将事务当作本地事务。因此，不写入TLOG。如果onePhase被设置为假，则2PC事务完全失败，并且具有非常复杂的错误结果。下面各部分将更详细地描述将如何对待这些可能的错误。
2.2在提交阶段期间的资源管理器错误
根据实施例，在提交阶段，TM调用在事务中参与的所有RM，并且要求它们提交。根据实施例，这以顺序方式而不是并行方式进行。根据替代实施例，可以使用并行方法来获得更短的事务等待时间，但是并行方法伴随有用于同步不同RM提交返回结果的额外开销。在TM架构背后的一个值得注意的方面是，要达到最大事务吞吐量而不是最小事务等待时间。
图5是根据本发明实施例的、图示在所有RM都已经成功准备时的时间点的活动图的流程图500。TM决定提交事务并且随后针对每个参与的RM调用提交。假设RM不能履行它在准备阶段做出的承诺，并且没有返回XA_OK给TM。取决于RM提供的特定错误代码，将采取不同的动作。TM针对参与事务的每个RM进行循环，因此图5中描述的执行流程将适用于每个RM。有时候，图5示出了针对RM调用忽略(forget)方法。根据实施例，这不是立即发生，而是在全部事务结束后发生。
在步骤501，如果XA_RB*或XA_RMERR为真，则处理进行到步骤502；如果不是，则处理进行到步骤506。XA_RB*代表一整类的返回代码：XA_RBROLLBACK、XA_RBCOMMFAIL、XA_RBDEADLOCK、XA_RBINTEGRITY、XA_RBOTHER、XA_RBPROTO、XA_RBTIMEOUT以及XA_RBTRANSIENT。对于TM行为而言，详细的XA_RB*原因是无关的。XA规范总结如下：“[XA_RB*]：资源管理器没有提交所进行的代表该事务分支的工作。在返回时，资源管理器已经回滚了该分支的工作，并且已经释放了所有占用的资源”。这基本上意味着事务被回滚，并且RM已经忽略了该事务。
对于XA_RMERR，XA规范说明如下：“在提交所执行的代表事务分支的工作时出现错误，并且该分支的工作已经被回滚。注意，返回该错误预示着对事务管理器而言发生了灾难性的事件，因为其他资源管理器可以成功提交它们的代表该分支的工作。该错误应当只在资源管理器推断它永远不能提交该分支并且它不能将该分支的资源保持在准备状态时返回。否则，应当返回[XA_RETRY]。
因此，我们可以确定该事务分支已经被回滚，并且事务不再处于未决状态。
在步骤502，如果失败的(故障)RM是事务中的第一RM，则TM改变其将事务作为整体提交的想法(并进行到步骤503)。取而代之，TM还将试图回滚其他RM，从而在事务结束后，再次达到一致状态(见步骤503)。否则，处理进行到步骤504。
在步骤503，TM决定回滚事务。不向TLOG写入有关TM这一想法改变的更新。这听起来可能令人惊讶，因为在TLOG中已经存在表示TM决定提交的条目。但是即使在尝试回滚期间发生崩溃，PTL处理器也将做出与TM相同的事情，因为它实现与TM相同的逻辑。这意味着PTL处理器将在TLOG中找到该事务。它将会试图提交该事务，发现第一RM回滚，这将导致回滚全部事务的决定。处理然后进行到步骤505。
在步骤504，TM确定知道不是第一事务分支的一个事务分支被回滚。因此，存在启发式混合情况(heuristic mixed situation)——其含义是TM确定知道事务不一致。TM试图提交其他RM。TM可以向管理员报告严重(Severe)错误，并且可以抛出(throw)HeuristicMixedException。
在步骤505，因为现在整个事务被标记为回滚，所以TM将回滚在事务中参与的所有RM。管理员只获得警告(warning)，因为事务仍然是一致的。最后，TM将抛出RollBackException。
在步骤506，如果XA_HEURRB为真，则处理进行到步骤507；如果不是，则处理进行到步骤514。
对于XA_HEURRB，XA规范说明如下：“由于启发式决定，已进行的代表指定事务分支的工作被回滚”。这完全等同于步骤501的情形，除了在这种情况中，即使该事务结束，RM也将记住(remenber)该事务，除非在步骤511中RM被允许忽略该事务。作为xa_commit函数的一部分，XA规范规定：“如果资源管理器已经启发式地完成了与*xid相关联的工作，则该函数仅仅报告资源管理器如何完成该事务分支。在事务管理器调用xa_forget()之前，资源管理器不能忽略以启发式方式完成的分支”。
步骤507-510分别类似于步骤502-505，除了处理从步骤509和510进行到步骤511。
在步骤511中，只要调用xa_forget()不是可配置的，处理就进行到步骤512。原则上，TM是否请求RM忽略该分支应当是可配置的。如果有知道如何使用该启发式事务DBMS状态的熟练的DBMS管理员，则应当将忽略该分支的任务交给DBMS管理员。如果是不能管理的环境，则TM应当从RM的存储器中移除该事务分支。
在步骤S512，只要没有异常，处理就进行到步骤513。如果在忽略过程中存在异常，则情况可能是也可能不是RM已经忽略了该分支。由于这对事务的一致性没有影响，所以TM在稍后不会重试针对该RM调用忽略。
在步骤513，因为步骤512没有导致严重问题，所以代替步骤512的随机性(contengency)，错误被记录到跟踪文件(trace)，以使感兴趣的管理员可以找出在忽略过程中出现的问题。
在步骤514，如果RM返回XA_HEURMIX，则处理进行到步骤515，否则处理进行到步骤516。
在步骤515，如果RM返回XA_HEURMIX，则它极可能是另一个事务管理器——尽管即使是DMBS也可能报告混合结果(mixed outcome)。作为整体事务现在被启发式地混合——因此，我们试图提交其它RM并且抛出HeuristicMixedException。之后，如同XA_HEURRB情况那样(步骤511等)，我们继续进行相同的XA忽略逻辑。
在步骤516，如果XA_HEURHAZ为真，则处理进行到步骤517，否则处理进行到步骤518。
在步骤517，如果遇到启发式危险(heuristic hazard)情形，则RM不知道事务分支的状态。这可能是暂时的情形或永久的情形。
根据实施例，将XA_HEURHAZ当作永久的返回代码。关于异常：JTA只知道RollbackException，HeuristicMixedException，HeuristicRollbackException，SecurityException，IllegalStateException和SystemException。根据实施例，HeuristicMixedException被SAP私有的SAPHeuristicHazardException所扩展，并将其抛出。这使得利用ex.getCause()捕获到该异常的应用具有作出反应的可能性。
根据将XA_HEURHAZ看作是短暂的返回代码的实施例，以提交事务为目的，该事务将被传送到“未决事务列表”(PTL)。PTL条目还包括关于事务中涉及的不同分支的结果的信息。PTL处理器将在稍后的时间负责执行PTL。如果拥有这个列表的进程死亡，则该列表中的该非持久条目也会丢失。这不会导致任何问题，因为PTL处理器将在恢复时在TLOG中再次找到该事务。因此，该事务不会被忽略。
在步骤5 1 8，如果XA_RETRY或XA_RMFAIL为真，则处理进行到步骤519；否则处理进行到步骤520。
在步骤519，TM将事务添加到PTL以用于提交，并且将危险状态报告给管理员。
关于XA_RETRY，DTP规范规定：“资源管理器此时不能提交事务分支。当阻挡状况存在并且TMNOWAIT被设置时，可以返回该值。然而注意，即使在TMNOWAIT没被设置时也可以返回该值(例如，如果当前不能获得必要的稳定存储)。如果在标志中设置了TMONEPHASE，则不能返回该值。代表*xid所占用的所有资源保持在准备状态，直到可以进行提交。事务管理器应当在稍后重新发出xa_commit()”。
对于XAER_RMFAIL，DTP规范规定：“发生错误，使得资源管理器不可用”。
概括来说，TM将不再延迟控制线程，并且试图在稍后的时间提交该分支。因此，将以提交为目的将该分支添加到PTL中。根据实施例，抛出的异常将是对JTA HeuristicMixedException进行扩展的SAP私有的SAPHeuristicHazard Exception。JTA异常被扩展的原因在于，在可能存在不一致事务(启发式危险)与确实存在不一致事务(启发式混合)之间存在差别。该差别在XA规范中是可见的，但是在JTA规范中丢失了。
在步骤520，如果TM到达这个活动，则表示在事务处理期间一些事情严重出错：可能是RM内的故障、TM内的故障或它们之间的故障。人类管理员可能也已经干预过事务状态。这里是可能的事情的列表(从DTP XA规范中引用的材料)：
·“[XAER_NOTA]资源管理器不知道指定的XID”。情况可能是管理员决定手动提交或回滚该未决事务。
·“[XAER_INVAL]指定了无效的参量(argument)”。这指向RM或RMXA驱动器内的错误。
·“[XAER_PROTO]在不适当的上下文中调用了例程”。这指向TM实现中的错误。
·“[XAER_ASYNC]在标志中设置了TMASYNC，并且已经超过了未完成的异步操作的最大数目，或者在资源管理器的xa_switch_t结构的标志元素中没有设置TMUSEASYNC”。JavaTM不支持异步事务的概念，因此这指向RM或RM XA驱动器中的错误。
·如果返回代码是其他内容，则它是DTP XA规范中没有提到的代码。这应该不会发生。
2.3在回滚阶段期间的资源管理器错误
如果在准备阶段期间分支之一投票赞成回滚，则TM将试图回滚全部事务。为此，根据实施例，TM以顺序的方式针对所有参与的RM进行循环。如果这些RM之一返回错误，则不会使TM停止继续回滚其它RM。除XA_OK之外的任何返回都被认为是错误——它可能是XA返回代码或另一个异常。
图6是根据本发明实施例的、概述TM将如何处理每个可能的XA返回代码的活动图的流程图600。
在步骤601，如果XA_RB为真，则处理进行到步骤602；否则处理进行到步骤603。XA_RB*代表一整类的返回代码：XA_RBROLLBACK，XA_RBCOMMIFAIL，XA_RBDEADLOCK，XA_RBINTEGRITY，XA_RBOTHER，XA_RBPROTO，XA_RBTIMEOUT以及XA_RBTRANSIENT。
在步骤602，对于TM行为而言，详细的XA_RB*原因是无关的。XA规范概括如下：“[XA_RB*]：资源管理器已经回滚了事务分支的工作，并且已经释放了所有占用的资源。在分支已经被标记为只回滚(rollback-only)时一般会返回这些值”。这基本上意味着事务被回滚，并且RM已经忽略了该事务。如果一些RM在准备期间投票赞成回滚，则这对于它们而言可能是正常行为。我们将利用警告通知管理员。
在步骤603，如果XA_HEURRB为真，则处理进行到步骤604；否则处理进行到步骤605。
在步骤604，尽管TM没有告诉它这样做，但是RM已经进行了启发式地回滚。XA规范规定：“由于启发式决定，所进行的代表指定事务分支的工作被回滚。资源管理器只有在已经成功准备了*xid时才可以返回该值”。因为反正TM也想要回滚，所以这将不会导致事务的不一致状态。TM抛出HeuristicRollbackException，并且将该RM的启发式决定通知给管理员。然后该处理进行到步骤607。
在步骤605，如果XA_HEURCOM或XA_HEURMIX为真，则处理进行到步骤606，否则处理进行到步骤610。
在步骤606，对于HEUR_COM，XA规范规定：“由于启发式决定，所进行的代表指定事务分支的工作被提交。资源管理器只有在已经成功准备了*xid时才可以返回该值”。对于HEUR_MIX，XA规范规定：“由于启发式决定，所进行的代表指定事务分支的工作被部分提交和部分回滚。资源管理器只有在已经成功准备了*xid时才可以返回该值”。
概括来说，事务现在明确处于不一致状态，因此TM将抛出HeuristicMixedException，并且将其通知给管理员。处理然后进行到步骤607。
在步骤607，无论何时只要RM给回启发式返回代码，TM就可以对该资源调用xa_forget。这是否应当发生可以由管理员配置。然后处理进行到步骤609。
在步骤608，如果在忽略过程中存在异常(见步骤609)，则情况可能是也可能不是RM已经忽略了该分支。由于这对事务的一致性没有影响，因此TM在稍后的时间不会重试对该RM调用忽略。作为替代，错误被记录到跟踪文件中，以使得感兴趣的管理员可以发现在忽略过程中的问题。
在步骤609，如果在忽略过程中存在异常，则处理进行到步骤608，否则处理停止。
在步骤610，如果XA_HEURHAZ为真，则处理进行到步骤611，否则处理进行到步骤612。
在步骤611，如果我们遇到启发式危险情形，则RM不知道事务分支的状态。这可能是暂时的情形或永久的情形。根据实施例，假设XA_HEURHAZ是永久的返回代码。关于异常：JTA只知道RollbackException、HeuristicMixedException、HeuristicRollbackException、SecurityException、IllegalStateException和SystemException。根据实施例，HeuristicMixedException被SAP私有的SAP HeuristicHazardException所扩展，并且将其抛出。这使利用ex.getCause()捕获该异常的应用具有作出反应的可能性。
根据XA_HEURHAZ被认为是短暂返回代码的实施例，以回滚为目的将事务传送到“未决事务列表”(PTL)。PTL条目还包括关于事务中涉及的不同分支的结果的信息。PTL处理器将在稍后的时间点负责执行该PTL。如果拥有该列表的进程死亡，则该列表中的该条目也会丢失。这不会造成任何问题，因为PTL处理器在恢复时将不会在TLOG中发现该事务，而是将其识别为对RM的recover()调用的结果。作为我们的假定终止(Presumed-Abort)策略的结果，PTL处理器将决定回滚全部事务。
在步骤612，如果XA_RMFAIL为真，则处理进行到步骤613；否则处理进行到步骤614。
在步骤613，对于XA_RMFAIL，XA规范写到：“出现错误，使得资源管理器不可用”。因为该状况可以是暂时的，所以TM将该事务作为意图决定回滚的条目放到PTL中。如果该条目丢失，则下一恢复过程将再次报告该分支，从而使回滚不会被忽略。
在步骤614，如果XA_RMERR为真，则处理进行到步骤615，否则处理进行到步骤616。
在步骤615，对于XA_RMERR，XA规范说明如下：“在回滚事务分支时出现的错误。当返回该错误时，资源管理器可以自由地忽略该分支，只要已经将该分支的状态通知给所有正在访问的控制线程即可”。
这种情形是有些异常的，并且对XA规范的作者来说这不是非常聪明的设计。它只发生在RM中的灾难性情形中。TM不知道事务分支的结果，这可以被当作是启发式危险情形。这里，使复杂性增加的是这样的事实：RM附加地告诉TM他可能忽略该事务。这意味着在稍后的时间调用该RM的恢复方法可能不再返回该事务。基本上，这意味着RM打破了它记住已经准备的事务的承诺。
一个实施例不对此执行特殊的逻辑。如果RM忽略它的事务，则TM对此无能为力。因为不清楚RM是否已经忽略了事务，所以如果管理员进行了配置，我们试图针对该RM调用忽略。我们返回SAPHeuristicHazardException。
在步骤616，如果TM到达本活动，则在事务处理期间一些事情严重出错：可能是RM内的故障、TM内的故障或它们之间的故障。也可能人类管理员已经干预过事务状态。这里是可能的事情的列表(从DTP XA规范中引用的材料)：
·“[XAER_NOTA]资源管理器不知道指定的XID”。如果管理器决定手动提交或回滚该未决事务，则可能是这种情况。
·“[XAER_INVAL]指定了无效的参量”。这指向RM或RM XA驱动器内的错误。
·“[XAER_PROTO]在不适当的上下文中调用了例程”。这指向TM实现中的错误。
·“[XAER_ASYNC]在标志中设置了TMASYNC，并且已经超过了未完成的异步操作的最大数目，或者在资源管理器的xa_switch_t结构的标志元素中没有设置TMUSEASYNC”。JavaTM不支持异步事务的概念，因此这指向RM或RM XA驱动器中的错误。
·如果返回代码是其他内容，则它是DTP XA规范中没有提到的代码。这应该永远不会发生。
2.4 XA资源重建(XA Resource Recreation)
应用服务器中的PTL处理器具有在恢复时重建XA资源管理器的任务。根据实施例，这项工作所需的所有信息将存储在事务日志中。这包括安全凭证(security credentials)和其它资源管理器特定属性。
(替代实施例研究所有部署的应用以找到所有涉及的XARM。实际上，这会耗费大量时间，因为在PTL处理器启动时扫描全部应用将需要相当多的CPU资源。)
非替代实施例的一个含意是RM安全凭证或其它属性的改变将不会对PTL处理器产生任何影响。PTL处理器将总是试图利用相同的证书和RM属性来完成事务，该证书和RM属性在事务开始时是有效的。
PTL处理器自身不需要知道如何重建RM。它可以将该任务委派给RM容器，该RM容器实现用于这种请求的唯一接口。目前存在三种不同风格的RM类型：
·泛型Java连接器资源(Generic Java Connector resources)-特别是出站资源适配器(outbound resource adapter)：连接器容器(aka连接器服务)负责这些RM的生命周期。这包括配置数据的部署和管理。
·数据源：数据源容器(aka DBPool(数据库池)服务)负责系统数据源和所有定制数据源的部署、配置和生命周期。数据源可以经由JDBC(JavaTM数据库连接)连接器UI(用户接口)或通过部署data-source.xml资源文件来创建。还可以部署外露javax.sql.DataSource接口的Java连接器资源适配器-但是这种RM将不由DBPool服务管理，而是由连接器服务管理。DBPool服务也负责数据源别名的管理，但是这些别名仅仅是对真实数据源对象的引用。对于其它RM容器，也存在相同的别名概念。
·JMS(JavaTM消息传递服务)队列/主题连接工厂(Queue/Topic ConnectionFactory)。JMS容器(aka JMS连接器服务)负责这些资源的管理。JMS工厂的配置数据从JMS连接器服务而不是从JMS提供者获得。
从连接管理的观点来看，DBPool服务和JMS连接器服务表现得如同JavaTM连接器容器一样。但是实际上，它们与应用服务器的JavaTM连接器容器严格分离，因为它们具有不同的部署方法和不同的配置UI。
从PTL处理器的观点来看，所有RM容器都是相似的。它们表现得如同XA资源工厂一样。一旦XA资源工厂启动，它就将它自身登记到TM。因此，PTL处理器可以询问TM，并且发现所需的XA资源工厂是否已经可用于服务XA资源创建请求。
2.5事务子系统的配合
应用服务器的事务行为是若干事务子系统交互的结果。所有系统一起配合进行事务处理和恢复。
2.5.1事务日志-高层视图
事务日志可以位于数据库中或文件系统中。如果选择了文件系统，则强烈推荐使用共享文件系统。即使文件系统不是共享的，事务恢复也将工作，但是没有即时(on-the-fly)恢复能力。下面的部分将对此更详细地说明。
每个集群节点具有一个事务管理器。该事务管理器在每次启动时创建新的事务日志。如果日志在DBMS中，则所有日志条目将共享相同的表，但是它将有可能区分来自不同的启动和不同的节点的条目。
在文件系统的情况中，每个日志将是一个分开的文件。TM是该TLOG的拥有者并且具有独占访问权。在图3中，该日志被称为TLog n(例如，320a)。
2.5.2事务日志-补充条目
如果TM正在运行而没有任何问题，则它将添加条目到TLOG。当然，典型的事务只在非常短的时间内有效-之后它可以被删除，并且不需要保持它的存储器。
根据实施例，这些删除操作不是立即执行，而是迟缓地执行。否则，对TLOG的写入操作将加倍。
如果事务结束，则将其添加到待删除牺牲者列表(Victim For DeletionList)。在TM中可以存在若干这种列表：每个TLGO一个。
·TM具有用于它在上次启动时创建的Tlog的待删除牺牲者列表。在它结束事务时，它将事务添加到该列表。
·PTL处理器可以对来自较早启动的TLOG进行操作。它维护用于这些TLOG中的每一个TLOG的待删除牺牲者列表。
·如果TM将有问题的事务提交到该PTL中，则PTL处理器也可以对当前有效的TLOG的事务进行操作。因此，PTL处理器也可以向有效TLOG的牺牲者列表添加条目。
待删除牺牲者列表是存储器内的结构。如果它达到一定的大小(例如，1000个条目)，则该1000个条目将从TLOG中删除。这对基于DBMS和文件系统的TLOG不同地发生：
·如果TLOG是基于DBMS的，则记录将利用单个DELETE SQL语句删除。
·如果TLOG是基于文件系统的，则将有一个或若干补充删除语句被添加到TLOG。这些条目使用范围，例如“删除事务501到1012”。识别事务的唯一号码是事务序列号。不需要完整的XID。
2.5.3 PTL处理器和PTL处理器控制器
PTL处理器负责将未决事务带到一致状态。如果当前有一些RM不可用，则该任务可能需要花费几小时，并且需要持续进行重试。因此，PTL处理器在它自己的线程中运行。
PTL包含关于XID、记录总体意图(事务应当回滚或提交)和每个分支的状态(分支已经提交、回滚或其状态未知)的信息。
如果没有工作要做(空的PTL)，则PTL处理器将自身停止，并且线程将返回到池中。PTL处理器的完整生命周期由PTL处理器控制器控制。该控制器容纳PTL，并且如果PTL处理器没在运行而在该PTL中存在条目，则控制器启动PTL处理器。
基本上，有两件事PTL处理器必须要做：关照未决事务，以及变为孤立事务日志的拥有者并且恢复其中的事务。
关照未决事务
如果TM遇到它不能立即处理事务的问题，则它将该事务添加到PTL，并且返回异常到调用的应用。
如果PTL处理器成功完成PTL中的条目，则它将该条目移除，并且将该事务放入待删除牺牲者列表中。在该列表中的事务条目将被从TLOG中迟缓地删除(见上文)。工作的成功完成也可以意味着事务经过了事务放弃超时，从而使得PTL处理器最终放弃该事务(可能在一天失败的尝试之后)。
变为孤立事务日志的拥有者
PTL处理器从第一个条目到最后一个条目贯穿PTL连续循环。如果它再次从第一个条目开始，则它检测  “夺取事务日志标志”是否被设置。
如果为是并且存在来自较早的启动的事务日志，则PTL处理器将试图变为对它们负责。如果其成功并且获得TLOG，则其将读入该TLOG。记住，TM永远不会对除了它在上次启动时创建的TLOG之外的任何TLOG感兴趣。
如果TLOG是基于文件的，则读入日志可以以两阶段方式进行：如已经提到的，可能是存在补充较早的条目的针对TLOG中的事务的删除语句。因此，PTL处理器首先将TLOG的所有条目读入存储器内的集结区域(in-memory staging area)。该区域将随着每个TLOG记录增长，并且如果在TLOG中发现删除语句，则该区域再次收缩。如果PTL处理器完成了对TLOG中的每个条目的读取，则它将只具有特定TLOG的最后条目，并且可能是更多的一些在上次崩溃或关机时未决的单个事务。
然后，在第二阶段中，该集结区域中的所有条目变为已处理，并且它们中不能得到立即解决的一些将被传送到PTL。
如果日志是基于DBMS的，则不需要集结区域。DBMS日志被当作文件系统情况下的集结区域那样对待。因此，将按照以下方式进行对集结区域或基于DBMS的TLOG的处理：
○首先，PTL处理器(PP)将读取属于该TLOG的RM条目，并对它们调用恢复。
○如果该PP针对RM成功完成上述处理，则它将结果存储在存储器内的恢复结果列表中。如果一个RM不可用，则该PP将用于该RM的NULL条目存储在恢复结果列表中。NULL条目不是空列表。空列表意味着RM可用并且没有未决事务。
○在该初始过程的恢复调用之后，PP逐个处理集结区域中的条目。它重构在该事务中涉及的所有RM的Id和条目的XID。
该XID将与恢复结果列表中的所有XID比较。
存在若干可能的结果：
*TLOG条目的XID不存在于任何恢复结果列表中。这意味着在任何RM中都不存在未决事务。因此，事务可以简单地被忽略。它被添加到用于该TLOG的待删除牺牲者列表。
*所涉及的RM之一的RM条目为空(null)，意味着该RM目前不可访问。因此，此时不能决定特定事务在该当前不可用的RM中是否仍然未决。因此，其被添加到PTL。
*XID在一些或全部所涉及的RM的恢复结果列表中。因此，PTL处理器将视图在这些未决RM上解决该XID。如果成功，则事务完成，并且将该事务添加到待删除牺牲者列表。如果不成功，则将其增加到PTL。
○如果在恢复结果列表中存在属于该TLOG但是不是该TLOG的一部分的XID，则回滚这些RM中的分支(这是假定终止策略)。
○必须注意PTL处理器试图对当前不可用的RM调用恢复，即使在用于该RM的PTL中不再存在条目也是如此。在该当前不可用的RM上仍然可能存在需要回滚的事务。
PTL处理器必须跟踪TLOG是否完全结束并且可以被删除。因此，它针对每个TLOG维护一个计数器，指示在PTL中有多少事务来自特定TLOG。如果该计数器达到零，则它从文件系统或相关的DBMS表中删除相关联的TLOG。
2.5.4 PTL处理中的单例模式(Singleton Pattern)：竞争TLOG
PTL处理器知道所有事务日志的位置，包括来自其它机器上的其它TM的事务日志。在基于文件系统的日志的情况下，所述位置是简单的共享文件夹。如果PTL处理器控制器中的“夺取事务日志标志”变为设置成真，则PTL处理器试图夺取所有可获得的事务日志。在这样做时，它与位于其它节点的PTL处理器竞争。每个事务日志只有一个拥有者。这实现了集群中的单例模式，这可常见于事务恢复的上下文中。
在图3中，可以看到位于节点m上的PTL处理器夺取了由位于节点m+1上的TM产生的TLOG。由PTL处理器负责来自另一节点的TM所产生的孤立TLOG没有任何坏处。因此，实施例没有实现任何TM到PTL处理器的亲和逻辑(affinity logic)。
因为当PTL处理器再次从PTL中的第一个条目开始时它只检查其“夺取事务日志”标志的状态，所以在各集群节点之间至少存在一些负载均衡。
概括来说，将“夺取事务日志标志”设置为真意味着启动恢复。但是谁负责设置该标志？
·PP控制订阅集群节点丢失事件(Cluster Node Loss event)。在节点丢失时，该标志被打开。这触发所有节点上的所有PTL处理器夺取孤立日志。这里的问题是，正常关机也触发该事件-因此PP控制必须确保在将该标志设置为真之前在本地节点上不启动关机。
·在不想依赖于集群节点丢失事件的情况下，可以额外使用java.util.timer来以预定义的时间可配置间隔将该标志设置为真。
如上所述，PTL处理器竞争TLOG。那么如何保证单个TLOG永远不会有两个拥有者呢？
·在基于文件系统的日志的情况下，同步是容易的：PTL处理器调用相应FileChannel上的tryLock方法。如果它得到锁定，则其它PTL处理器失败。如果节点崩溃，则操作系统从文件移除锁定。
·如果TLOG存在于DBMS中，则将存在TLOG表。对于每个逻辑TLOG，在该表中存在一个记录。该记录包含拥有者和时间租用(time-lease)列。如果PP拥有TLOG，则它在该表格中制作租用条目，指定其自身为拥有者，并且提供GMT时间，在该时间之前它拥有该TLOG。如果它想要保留该TLOG，则它必须在租用时间结束前续租(renew)该条目。如果另一PP发现过期的TLOG拥有者条目，则它认为它的拥有者已死。这里的问题是，这种基于租用的方式引入了等待时间。
○TM是TLOG的拥有者并且将其预留可配置的量10(例如，10分钟)。
○该TM崩溃，激发节点丢失事件。
○另一节点上的PP扫描日志，并且看到该日志仍然被预留。因此，正常地它将不会试图变为对该日志负责，尽管目前不再有任何拥有者关照该TLOG。这延迟了正在进行的恢复。
○根据实施例的一个解决方案是，PP控制器知道崩溃的节点的Id(标识符)。因此，如果崩溃的节点是TLOG的拥有者，则租用可能不再有效。该实施例的一个缺点是，崩溃的节点可能已经再次启动，因此该TLOG实际上是全新的TLOG，或者是崩溃的节点的PP已经在关照的TLOG。
2.5.5节点启动
为了说明事务组件的配合，这里是在集群启动期间执行的过程：
·首先，节点上的TM启动。它创建全新的事务日志并且独占地使用该事务日志。
·之后，“夺取TL”标志将被设置为真。这将启动该节点上的PTL处理器。
·PTL处理器打开它可以获得的第一孤立事务日志。它读入在该日志中使用的所有RM。这是简单的，因为RM信息没有混合到正常的TLOG中，而是可作为额外的条目获得(实际上，是作为分开的文件或分开的表)。
·PTL处理器创建重建RM所需的XA资源工厂的列表。例如，可能存在5个数据源和3个JCA(J2EE连接器架构)适配器，因此结果将是需要一个JDBC XA资源(XAResource)工厂和一个JCAXA资源工厂。
·在该时间期间，服务器也独立启动属于该服务器基础架构的XA资源工厂。如果XA资源工厂准备好接收请求，则它将它自己登记到TM。因此，TM知道所有可用的XA资源工厂。
·PTL处理器利用TM检查是否所有需要的XA资源工厂都已经启动。如果不是，则它等待一些时间并重试。即使不是所有的RM都出现，也已经可以恢复一些事务(在本文中稍后描述)。
·PTL处理器使用XA资源工厂重建所有涉及的RM。
·PTL处理器针对所有RM调用恢复，并且将结果存储在存储器内(in-memory)。
·PTL处理器读入TLOG中的每个条目，与恢复结果比较并且填充(populate)PTL。
·PTL处理器试图打开下一个TLOG，并且重复上面的后几个步骤。
如可以看到的，每次节点启动都启动恢复过程。因为这个原因，即使TLOG位于非共享文件系统的顶部，也将存在事务恢复。恢复将不是即时的，而是在崩溃节点的下一次启动期间。
当然，即时恢复是推荐的，因为其几乎是立即发生。恢复发生的越快，RM作出启发式决定的可能性越小。
2.6事务超时
2.6.1准备之前的XA事务超时
存在不同的可能性来使用JTA定义事务超时。这些不同的可能性之一是在调用当前javax.transaction.UserTransaction实例上开始(begin)之前调用同一实例上的setTransactionTimeout(设置事务超时)方法。
在分布式事务的情况下，该超时是事务必须在其间达到准备状态的时间跨度。如果没有通过编程定义超时，则可以采用系统范围的默认参数(system wide default)。应当可以额外定义优先于系统默认参数的资源管理器级别上的超时。因此，可以对异常慢的RM的情况建模。
TM通过在调用XAResource.start之前调用XAResource.setTransactionTimeout()，来将该超时传播到所涉及的RM(只有在存在任何定义的超时的情况下)。
2.6.2 XA事务放弃时间
如果事务达到准备状态，则它必须在XA事务放弃时间跨度内完成。该超时被配置为系统范围的设置-典型的默认值为20小时。如果TM不能在该时间内将事务带到一致状态，则它将放弃该特定事务，并以启发式结果记录该事务(很可能事务状态将是HEURHAZ)。
3 XID结构和事务日志版本
3.1介绍
XID是TM分发给RM以标记事务分支的识别符。RM执行在该XID下它的可恢复的工作。如果系统崩溃，TM将在稍后的时间询问RM关于其未决事务。RM将返回XID，因此TM必须能够识别它是否是该XID的始发者，并且随后负责该事务的恢复。
XA规范对TM的实现者给予了一些关于XID不同部分的长度和内容的自由度。所述部分是格式ID(Format ID)、全局事务ID(Global Transaction ID)、和分支限定符(Branch Qualifier)。
3.2事务日志的唯一标识
PTL处理器负责恢复属于一组事务日志的事务。这些事务日志可能来自TM的之前的启动。但是当前产生的事务日志也定义PTL处理器必须关照的某组事务。现在，处理器怎样才能决定RM中未决的事务是否属于它所负责的一组TLOG呢？答案很简单：
·首先，它检查格式ID是否为“SAP1”。如果是，则它知道它是创建事务的SAP NW(NetWeaver)JS(Javascript)TM。
·然后，它比较编码到XID中的TLOG版本是否等于它当前负责的TLOG版本之一。TLOG版本由以下部分组成：系统ID(System ID)、节点ID(Node ID)和TM启动时间(TM Startup Time)。系统ID标识系统。节点ID唯一地标识集群内的节点。实例ID已经被混合到该ID中，因此不需要单独添加。TM启动时间是GMT格式的TM的启动日期/时间。粒度为毫秒。一毫秒内TM两次启动被认为是不可能的。替代实施例可以调整这些参数。
3.3 XID结构
XID结构的不同部分包括格式ID(Format ID)、扩展全局事务ID(Extended Global Transaction ID)和分支限定符(Branch Qualifier)。格式ID为“SAP1”(根据实施例)。在替代实施例中，“1”可以用版本信息替代。分支限定符唯一地标识TLOG内的RM。
扩展全局事务ID包括全局事务ID(Global Transaction ID)和分支迭代器(Branch Iterator)。如果JavaTM EE res-sharing-score被设置为不可共享，则分支迭代器可能在少有的环境中使用。
全局事务ID包括TLOG版本(TLOG version)、事务序列号(Transaction Sequence number)、事务出生时间(Transaction Birth Time)、事务放弃时间(Transaction Abandon Time)和TX名称标识符(TX Name Identifier)。TLOG版本标识事务日志实例。事务序列号唯一地标识TLOG内的事务。事务出生时间是GMT格式的TM创建事务的日期和时间。事务放弃时间是事务将被放弃的日期和时间。TX名称标识符是所使用的事务名称的唯一标识符。
基本上可以区分两种属性：事务系统的正常工作所需的属性和驮载封装的(piggy-packed)并给出关于特定事务的附加信息的属性。记住，由于假定终止策略，有时候XID是在事务恢复期间TM具有的唯一信息。当TM决定回滚事务、因此不存在TLOG条目，但RM返回XID作为恢复调用的结果时，就是这种情况。
以下是对不同属性的目的的描述：
3.3.1事务序列号
该号码唯一地标识TLOG内的事务。如果TLOG是基于DBMS的，则该序列号将是索引列。如果TM启动，则该号码从零开始，并且不停地增加。如果每秒将有10000个事务，则8字节的长度将足以支持几百万年的正常运行时间。允许号码之间有中断(gap)。
3.3.2事务出生时间
该属性只是信息性的。如果TM创建事务，则GMT格式的所述时间被设置。其对于数据库管理员找出事务有问题的原因可能是有用的，因为它给出了应当浏览哪部分日志以确认问题的根本原因的线索。
3.3.3事务放弃时间
格式为GMT-如果创建事务，则该属性被设置。如果PTL处理器稍后发现该时间，则它知道它何时可以放弃该事务。即使一些或全部被涉及的RM都不可达，情况也是如此。如果当前时间是在该放弃时间之后，则PTL处理器可以自由地放弃该事务并且擦除它具有的关于该事务的所有存储器。
3.3.4事务名称标识符
将完整的事务名称存储在GTRID中会使XID膨胀。作为替代方式，只存储指向事务名称表中的条目的4字节整数值。
3.3.5分支迭代器
一些Java EE规范允许定义资源引用。这包括res-sharing-scope元素的定义。它指定通过给定资源管理器连接工厂引用获得的连接是否可以共享。如果指定了该院色的值，则该元素的值必须是以下两种之一：可共享(Shareable)或不可共享(Unshareable)。默认值为可共享。这里是来自EJB部署描述符的示例：
<resource-ref>
<res-ref-name>jdbc/CustomerDBMS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Unshareable</res-sharing-scope>
</resource-ref>
将该属性设置为不可共享几乎在所有情况下都是坏主意。这意味着不允许连接共享，并且结果是应用具有到相同RM的若干物理连接。实际的示例：
·通过TM启动具有XID tx4711的事务。
·应用获得到RM的新的连接。对于该连接，总是存在相关联的XA资源实例。调用该实例XAResource 1。TM将该连接与XID 4711关联：
XAResource1.start(tx4711)；
·现在，应用创建到相同RM的第二连接。调用与该连接XAResource2相关联的XA资源。正常地，TM将发出以下代码：
XAResource2.start(tx4711)；
不幸的是，这将不能工作，因为XAResource1和XAResource2指向相同的RM。该RM将抱怨已经存在一个TM利用该全局事务ID启动了事务。该抱怨是有效的，因为RM不能知道这两个连接背后的TM是同一个。RM必须假设存在两个访问它的TM，并且可能其中一个将在稍后的时间点请求提交事务，而另一个将请求回滚事务。因此，它不能允许两个物理连接与相同的XID关联。
克服该问题的一种可能是对这些连接使用不同的全局事务ID。准确来说，该想法提供1字节长分支迭代器。第一连接获得分支迭代器0，并且到相同RM的下一个连接获得递增1的分支迭代器。以此类推。这将单个事务内到单个RM的连接数目限制为256，超过256将抛出异常。
对于RM而言，所述两个事务根本互不相关。因此如果资源共享被设置为不可共享，则即使在单个RM内也会存在2PC语义(2PC semantics)。
对于TM而言，它仍然是单个事务，并且如果TM决定要提交，则在TLOG中只有一个记录。
3.3.6扩展全局事务ID
全局事务ID是应用服务器(例如TM和PP)内的事务的表示。该ID还标识TLOG中的事务。
外部RM看不到该全局事务ID，而是全局事务ID和分支迭代器的组合。两种属性一起形成扩展全局事务ID。
4.事务日志结构
4.1事务日志的实体
事务日志存储实现事务恢复所需的不同实体。这些实体包括TLOG实体、TLOG条目实体、事务名称实体、RM实体和存储器内实体(In-MemoryEntities)。
4.1.1 TLOG实体
TLOG实体对每个逻辑事务日志具有一个实例(在DBMS情况中转换为一个记录)。TLOG的拥有者能够通过更新该实例以及在拥有者属性中提供它的标识并在leasedUntill属性中提供GMT时间(直到该GMT时间预留都有效)，来预留完整的日志。所述时间之后，认为TLOG对任何人可用。
拥有者是拥有者的角色(TM或PP)和集群节点ID的组合。
在文件系统的情况下，该实体可能不是必需的。文件名称可以用作版本标识符，并且通过OS控制锁定。
4.1.2 TLOG条目实体
TM生成识别事务的全局事务ID。参与该事务的每个RM是分支，并且获得由TM分配的分支Id。该分支Id对于TM的整个生命周期保持相同，这意味着从TM启动一直到关机保持相同。如果事务使用之前TM不知道的新的RM，则TM将该RM添加到RM实体。分支Id的生成可以简单地通过增加TM内部计数器来进行。
分支IID存储在TLOG条目中的原因如下：
·考虑存在包括RM a、b、c的事务tx 1。
·PTL处理器知道，对于完整的日志，RM a、b、c、d被涉及。
·因此，在恢复过程开始时，PTL处理器针对RM a、b、c、d的恢复。但是RM d由于暂时或永久的故障而当前不可用。
·尽管RM d不可用，PTL处理器仍可以恢复tx 1，因为它确定知道RMd没有被涉及。
如果TLOG是基于文件的，则应当将校验和加到每个条目的结尾，例如，java.util.zip.CRC32。因此，很清楚我们具有有效的记录或死亡的TM的片段。
4.1.3事务名称实体
SAP TM允许另外指定人类可读的事务名称。在恢复服务稍后需要将问题报告给管理员的情况下这是有用的。代替报告“Xid 4711具有启发式结果”，消息可以是“事务“OrderBooking”具有启发式结果”。事务名称永远不应当特定于如“order#12345”的事务实例，它更像是事务分类符。
事务名称的另一优点是监控可以变得更有意义。可以根据事务名称向下钻取(drill down)事务吞吐量和故障。
TM在它对任何RM进行第一次准备调用前写入事务名称实体。在TLOG自身中，只存储较短的transactionNameId(事务名称ID)，其是全局事务ID的一部分。如果应用没有使用事务名称，则将不写入记录。
利用事务名称存在一个风险：如果应用使用事务实例特定的名称，则结果是TM除了要更新TLOG之外，还要对每个事务执行一次到该条目的写操作。这将使写入操作的数量加倍。同样，事务名称表将无限地增长。
因此，根据实施例，可以存在对事务名称的最大数目的可配置的限制，例如1000。该数目后，新的事务名称将被忽略。或者，可以实现用于内部事务名称高速缓存的LRU(最近最少使用)策略。因为允许高数量的事务名称没有明显好处，所以这有可能矫枉过正。
4.1.4 RM实体
如已经提到的，TM创建在其生命周期期间该TM所使用的所有RM的持久实体。该信息必须足以用于在恢复时重建XA资源管理器。这暗示着要存储XAResourceFactoryId(XA资源工厂ID)，指向能够创建该类型的XAResource(XA资源)的资源工厂。该工厂也具有名称、属性和执行重建任务的凭证。如果TLOG是基于文件系统的，则RM实体变为它自己的文件。因为它存储凭证，所以它将被加密。
在TLOG实体被消化(digest)前，RM实体将被PTL处理器读入。将针对RM实体内的所有RM进行恢复调用，此后，TLOG条目将被处理以填充PTL。
4.1.5存储器内实体、RM中的事务表示和实体生命周期
除了持久实体外，还存在事务的存储器内表示和RM中的事务的表示。下面的过程解释不同的实体如何被填充：
·首先，TM创建全局事务Id。
·应用可以可选地给事务分配事务名称。它应当在第一个RM被接触前进行该操作。
·TM通过将该事务名称与内部事务名称高速缓存进行比较来检查该事务名称是否已知。如果是，则它取得高速缓存中作为事务名称标识符的位置。如果不是，则其将事务名称添加到内部高速缓存，分配事务名称标识符，并将事务名称写到事务名称实体中。(该步骤可以被延迟，直到第一个xa_star()发生)。
4.2事务日志生命周期
每个分布式事务都被添加到事务日志中。如果事务完成，则不必再保留存储空间，因此特定事务可以变为待删除的牺牲者。为了减少对盘/DBMS的写操作，该删除操作应当迟缓地发生。这种迟缓的方式可以导致这样的效果：在日志中存在已经完成的事务。以这种情况不会产生问题的方式设计整个PTL处理器：在恢复时，PTL处理器将发现日志中完成的事务，并且发现没有RM返回相称的Xid。因此，将假设对该事务不再感兴趣。
4.2.1基于DBMS的事务日志
TM具有存储器内数据结构，其对完成的事务进行跟踪。在预定义数目的条目之后(例如，100)，TM将以以下方式对TLOG条目表执行单个删除操作：
DELETE FROM TLOG_ENTRIES WHERE XID IN(Xid1，Xid2，...，Xid100)
PTL处理器将以类似方式进行条目的删除。如果便随着填充PTL来进行该操作，则它知道在TLOG中的但是不再有效的所有Xid。将发出与上面示出的类似的SQL删除操作。
如果TM遇到正常关机过程并且不再有有效事务，则它可以自由地额外删除TLOG表中代表整个事务日志的记录。
如果对于某个事务日志恢复服务不再具有未决事务，则其通过删除TLOG表中代表该事务日志的记录来附加地删除整个事务日志。
4.2.2基于文件系统的事务日志
如果TLOG是基于文件系统的，则必须注意新文件中的溢出。由于TM知道所有有效的和未决的事务，所以如果文件达到预定义的可配置的实体数量(例如，1000)，则发生下面的溢出过程：
·新的事务日志文件被创建。
·新的RM日志文件被创建。
·所有有效的和未决的事务被复制到新的日志文件。
·由这些有效的和未决的事务使用的所有RM被复制到新的RM日志。
·指向旧文件的所有内部数据结构将被更新，以使它们指向新文件。
·删除旧文件(TLOG和RM日志)。
恢复服务不删除任何单独的实体。但是其检查其是否处理了属于某个事务日志的最后的未决条目。如果是，则其删除该最后的未决实体所属于的TLOG和RM日志。因为存在典型为大约一天的事务放弃超时，所以在最后的条目被添加之后，整个事务日志不能存活超过一天。
5.插入的事务管理器(Interposed Transaction Manager)
在大多数使用情景中，应用服务器在它的事务的完全控制之下。对此的一个显著例外是由Java连接器架构引起的，Java连接器架构从发布版本1.5开始。在该规范中，定义资源适配器可以将引入的事务(imported transaction)传播到应用服务器，以使得应用服务器和随后的参与者可以进行作为该引入事务的一部分的工作。
该规约允许资源适配器流入(flow-in)事务完成和由企业信息系统(EIS)发起的崩溃恢复调用。
这样概括，应用服务器用作对外部事务管理器的普通RM。为了达到这个目的，应用服务器容纳插入的TM：它向外部TM提供像RM那样的接口，并且像普通TM那样协调内部RM。
进入的事务的XID将被映射到由插入的TM发出的内部Xid上。这两者之间的映射至少在准备时间必须是持久的。
5.1 插入的事务管理器的事务超时
5.1.1 RM事务放弃时间
JCA规范允许JCA适配器处理作为相同事务的部分的若干入站(in-bound)请求。对于每个请求，适配器能够设置事务超时，以作为该请求的一部分。适配器通过创建ExecutionContext并调用关于它的SetTransactionTimeout方法来达到这一目的。ExecutionContext将和适配器创建的工作(Work)实例一起被提交(submit)给应用服务器的工作管理器(WorkManager)。
插入的TM将只使用发起事务的第一请求的事务超时。它将该时间解释为对包括随后请求的整个事务允许的时间跨度。基于该超时和当前系统时间，插入的TM将计算GMT格式的绝对时间，在该时间后TM可以自由地放弃事务。
在已经达到准备状态的分布式事务的情况下，放弃事务被转换为做出启发式决定-因此该超时的影响相当显著。
如果JCA适配器没有定义超时，则将采用默认超时。这应当被定义为在系统范围内，或者在适配器的部署描述符中定义。
5.1.2准备之前的RM事务超时
事务分支可能在它达到准备之前已经超时。在准备前回滚事务分支应当永远不会导致整个事务的启发式结果。因此，典型地，预期准备前的事务超时短于事务放弃超时。因为Java连接器规范没有定义这样的超时，所以根据实施例设置SAP私有的超时。这种定义可以是系统范围内的设置或适配器特定的设置。
5.2插入的事务管理器的事务日志
插入的TM将具有单独的事务日志，其包括以下信息：
·外部TM的进入的Xid。
·映射到外部Xid的应用服务器TM的内部Xid。当处理内部RM时，只使用该Xid。
·GMT格式的事务放弃时间。
·在事务中参与的RM的标识，包括它们的投票。
·在整个事务已经被启发式地完成的情况下整个事务的结果(HEURRB，HEURCOM，HEURMIX，HEURHAZ)。
在已经经过了事务放弃时间之后，插入的TM将试图启发式地回滚事务。该操作的结果将被存储在事务日志中，因此可以在下一次外部TM试图继续该事务或对该插入的TM调用恢复时报告该结果。插入的TM将保留关于启发式完成的事务的条目，直到外部RM调用关于它的忽略为止。
5.3集群内的插入的事务管理器
如同许多JavaTM EE规范一样，JavaTM连接器架构不处理成集群环境中的故障转移(fail-over)和负载分布。取决于应用的逻辑和企业信息系统(EIS)发送给应用的消息的内容，可以区分的两种情况：
·消息需要在所有集群节点上被处理。这种情况的示例是股票报价消息，其更新股票的市场价格的集群节点内部表示。
·消息只可以由集群内的单个节点接收。示例可以是接收在DBMS中创建新的客户记录的请求的“新客户”事件。
根据实施例，两种情况都被支持。连接器规范授权Message Driven beans(消息驱动beans)作为来自EIS的消息的消费者(consumer)。因此，打开消息的并行传递的方式是在MDB[message driven beans]的DD[数据描述]将“topic-on-all-nodes”设置为真(用于该设置的术语“topic”(主题)可能会造成误导，因为它指向JMS，但是是历史决定的结果)。
另一个问题是EIS是否将来自不同集群节点上的EIS特定适配器的进入连接识别为相同逻辑的EIS适配器。作为旁注，这里连接请求总是源自适配器而不是EIS。行为只从属于EIS和特定适配器。再次，可以区分两种情况：
·EIS假设所有进入的连接都是在逻辑上相同的。这可以类似于以下情况：Peter(适配器)可能使用他的移动电话呼叫Thomas(EIS)。连接因为移动电话的电池没电而断开，因此Peter再次呼叫-这次使用他的办公室电话。Thomas能够继续与Peter交谈，因为Peter将他自己标识为与以前相同的Peter。
·EIS假设所有进入的连接都是不同的。在上述示例中，Thomas将坚持呼叫他并使用他的办公室电话的Peter是不同的Peter，因为在Thomas的电话上显示的进入呼叫者ID是不同的。
图7A-7D示出了根据本发明实施例的四种使用情况。
在图7A中，将topic-on-all-nodes设置为真，并且EIS正与两个节点都在交谈，假设它们在逻辑上是一个节点。可能的是，EIS发送消息给一个节点，准备另一个节点上的事务，并最终提交到其它地方。
为了支持该行为，需要集群范围内的事务登记，而这可能是严重的瓶颈。因此，根据本发明的实施例，决定不支持这种情景。
在图7B中，与图7A的不同之处在于EIS认为各节点是不同的。结果，对于节点而言事务将是严格地本地的。如果一个节点崩溃，则EIS不可能调用恢复，直到该节点再次启动。根据实施例，支持这种情景。
在图7C中，将topic-on-all-nodes设置为假。如果节点1崩溃，则基于应用服务器的故障转移支持，消息处理将被自动切换到节点2。需要说明的重要一点是，将没有自动故障恢复(fail-back)。即使节点1再次启动，它也将不再消费来自EIS的消息。实施例支持该情景，但是具有一些副作用：如果在故障转移之前事务启动但没有结束，则应用下面的规则：
·如果事务仍然是在准备状态之前，则它将被所涉及的后端RM自动回滚。否则，将需要共享事务登记。
·如果事务是在准备之后，则在插入的TM的事务日志中将存在条目。节点2将接收对于在节点1上启动的事务的提交/回滚/恢复请求。为了允许该操作，插入的TM的事务日志必须共享。
在图7D中，topic-on-all-nodes被设置为假。在节点1崩溃之后，节点2中的适配器将建立到EIS的连接。EIS将不会将节点2上的适配器识别为与崩溃的适配器相关。因此，EIS将会试图继续任何在故障转移时间之前启动的事务。尽管实施例实现了这一情景，但是也可以将其归档为不被支持，因为它导致启发式事务结果。
6.事务日志写加速器
与非XA类型的处理相比，两阶段提交事务处理由于其物理I/O而显得非常繁重。这主要是由于在单个事务中需要若干盘力(disc force)的事实。作为示例，考虑涉及两个RDBM的事务，这两个RDBM全部写入相同的盘：
·在准备时，两个RM都具有盘力-每个RM 1个-总共2个。
·如果TM决定提交，则其写入TLOG-另一盘力。
·两个RM都提交-另外2个盘力。
·稍后，TLOG条目被清除-但是这不需要再一次的盘力。
因此结果是总共5个盘力，而不是使用本地事务的情况下的单个盘力。盘力所需要的时间量可以预期为在5到50毫秒之间，这取决于可用的盘。如果事务有效载荷小，则盘同步可能变为事务处理中的主要部分，因此盘同步需要尽快。
实施例通过将对TLOG的更新分组到一起并且将其作为对文件系统或DBMS的单个操作的一部分来执行，而增加吞吐量。实际上，这意味着访问TM的一组应用线程被延迟，直到完成同步，因为它们全部在单个同步操作中被分组到一起。
·低于临界吞吐量，将对TLOG的更新分组到一起没有意义。对日志的每个更新通过应用线程本身来执行。因此，每个同步操作对TLOG的更新的数量为1。
·高于临界吞吐量，I/O变为瓶颈。想要添加到TLOG的应用线程多于盘或DBMS能够处理的应用线程。这引入了对系统能够实现的最大吞吐量的严重限制。
为了克服这一问题，将不同应用线程的更新分组到一起，并且将其作为针对TLOG的单个同步操作来执行。如果TM的事务吞吐量增加，则越来越多的对TLOG的更新被分组到一起。
根据实施例，TM实现随后支持两种模式：
·低吞吐量模式：TLOG在应用线程内更新。
·TLOG批处理模式：在单独的线程中进行TLOG更新。
这里的一个挑战是决定何时切换到TLOG批处理模式是有利的，换句话说，如何定义临界吞吐量数量。该数量取决于硬件。实施例实现了自适应机制，其通过尝试以下步骤来找出该数量：
·在TLOG批处理模式中，每个应用线程将它的TLOG更新附加到缓冲器中。
·单独的线程获取缓冲器的内容并将其写入TLOG。如果该线程完成写入，则它将发现缓冲器已经被填入了许多添加到该缓冲器的应用线程。该线程将再次获取缓冲器并释放等待的应用线程。以此类推。
·如果该线程返回并且看到在缓冲器中没有或只有一个条目在等待，则该线程知道它不被真正需要。不存在要分组的请求。它会将EmptyCycle计数器增加1。
·如果线程发现缓冲器被填入了多于1个条目，则其将NonEmptyCycle增加1，并且将EmptyCycle计数器设置回0。
·如果EmptyCycle计数器超过预定义的空周期的最大数目(例如，100)，则线程切换到低吞吐量模式并且去激活它自己。这是TLOG批处理子系统的退出准则。批处理子系统不立即去激活它自己的原因在于要实现滞后行为。如果事务系统在临界吞吐量附近，则它将不会在LOG批处理和低吞吐量模式之间持续地振荡，而是只有当存在较长时间跨度的低事务需求时的振荡。
在现在清楚了何时TM会将TLOG批处理模式关闭后，问题是何时将它打开。为此，可以使用NonEmptyCycle计数器：如果NonEmptyCycle计数器小，则意味着TLOG批处理子系统实际上没有很多事情要做。换句话说，将其从最开始就打开是没有意义的。
另一方面，TM知道当前的事务吞吐量。这通过对总的事务量计数并将它们除以它们所花费的时间来实现(例如，全部100个事务或全部10秒，计算吞吐量)。
因此，如果NonEmptyCycle为低，则可以得出结论：在当前事务速率下将批处理模式打开是没有意义的。这定义了对于临界吞吐量数量的新的猜测。如果当前事务速率高于临界吞吐量数量，则TM再次将TLOG批处理模式打开。在一些迭代之后，临界吞吐量值将达到与当前硬件设备相称的速率。
图8是用于实现本发明实施例的示例计算机系统和网络1400的方框图。计算机系统1410包括总线1405或用于传送信息的其它通信机制、以及与总线1405耦合的用于处理信息的处理器1401。计算机系统1410还包括耦合到总线1405的用于存储由处理器1401执行的信息和指令的存储器1402，所述信息和指令包括用于执行上述技术的信息和指令。该存储器还可以用于存储在执行由处理器1401执行的指令期间的临时变量或其它中间信息。该存储器的可能实现可以是，但是不限于，随机存取存储器(RAM)、只读存储器(ROM)或它们两者。还提供存储设备1403用于存储信息和指令。存储设备的通常形式包括例如硬盘驱动器、磁盘、光盘、CD-ROM、DVD、闪存、USB存储卡、或计算机可以读取的任何其它介质。例如，存储设备1403可以包括用于执行上述技术或实现上述结构的源代码、二进制代码、或软件文件。
计算机系统1410可以经由总线1405耦合到显示器1412，该显示器1412诸如阴极射线管(CRT)或液晶显示器(LCD)，用于显示信息给计算机用户。诸如键盘和/或鼠标的输入设备1411耦合到总线1405，用于将信息和命令选择从用户传送到处理器1401。这些组件的组合允许用户与系统通信。在一些系统中，总线1405可以分成多条专用总线。
计算机系统1410还包括与总线1405耦合的网络接口1404。网络接口1404可以提供计算机系统1410和本地网络1420之间的双向数据通信。例如，网络接口1404可以是数字用户线(DSL)或调制解调器，用于通过电话线提供数据通信连接。网络接口的另一示例是局域网(LAN)卡，用于提供到兼容的LAN的数据通信连接。无线链路也是另一示例。在任何这种实现中，网络接口1404发送和接收携带表示各种信息的数字数据流的电、电磁或光信号。
计算机系统1410可以通过网络接口1404发送和接收信息到内联网或因特网1430，该信息包括消息或其它接口动作。在因特网示例中，软件组件或服务可以驻留在遍及网络的多个不同的计算机系统1410或服务器1431、1432、1433、1434和1435上。服务器1431可以通过因特网1430、本地网络1420和网络接口1404将来自一个组件的动作或消息传输给计算机系统1410上的组件。
计算机系统和网络1400可以以客户端服务器方式配置。客户端1415可以包括类似于计算机系统1410的组件的组件。
更具体地，计算机系统1410可以实现应用服务器(例如，图2中的114d)。
上面的描述说明了本发明的各种实施例以及本发明的各方面可以如何实现的示例。上面的示例和实施例不应当被认为是仅有的实施例，而是呈现来说明由权利要求定义的本发明的灵活性和优点的。基于上面的公开内容和权利要求，其它安排、实施例、实现和等效方式对本领域技术人员将是明显的，并且可以被使用而不偏离权利要求定义的本发明的范围。

Claims (18)

1.一种用于分布式计算环境中的事务恢复的系统，包括：
事务日志服务器，其存储共享事务日志；
多个应用服务器，其实现分布式事务应用，并且在使用分布式事务应用执行事务时，访问所述共享事务日志；以及
多个资源服务器，其存储数据，并根据事务与所述多个应用服务器操作以访问数据，
其中所述多个应用服务器、多个资源服务器和事务日志服务器通过经由网络连接的多个硬件设备实现，以及
其中如果所述多个应用服务器中的应用服务器变为故障应用服务器，则有效应用服务器承担之前由所述故障应用服务器访问的共享事务日志的部分的责任。
2.如权利要求1所述的系统，其中所述事务日志服务器包括文件系统和数据库管理系统之一。
3.如权利要求1所述的系统，其中所述多个应用服务器中的应用服务器包括：
事务管理器，其执行事务；以及
未决事务列表处理器，其访问所述共享事务日志。
4.如权利要求1所述的系统，其中所述多个应用服务器中的第一应用服务器包括：
未决事务列表处理器，其访问与所述第一应用服务器对应的共享事务日志的第一部分，并且访问之前由所述故障应用服务器访问的共享事务日志的部分。
5.如权利要求1所述的系统，其中所述共享事务日志包括多个逻辑事务日志，其中所述多个逻辑事务日志中的每一个与所述多个应用服务器中相应的一个应用服务器以及相应的运行标识符相关联。
6.如权利要求1所述的系统，其中所述多个应用服务器中的应用服务器包括：
未决事务列表，其存储多个未决事务；
未决事务列表处理器，其访问所述共享事务日志以及所述未决事务列表。
7.如权利要求1所述的系统，其中所述多个应用服务器中的应用服务器包括：
待删除牺牲者列表，其存储要从所述共享事务日志中删除的条目；
事务管理器，其在所述事务管理器已经完成了完成的事务时，将所述完成的事务从所述共享事务日志添加到所述待删除牺牲者列表，并且在所述待删除牺牲者列表达到定义的大小时，将所述待删除牺牲者列表中的条目从所述共享事务日志中删除。
8.如权利要求1所述的系统，其中所述多个应用服务器中的应用服务器包括：
事务管理器，其对所述共享事务日志执行分组更新。
9.一种分布式计算环境中的事务恢复的计算机实现的方法，包括：
利用事务日志服务器存储共享事务日志；
利用多个应用服务器实现分布式事务应用，在使用所述分布式事务应用执行事务时，所述分布式事务应用访问所述共享事务日志；以及
利用多个资源服务器存储数据，其中所述多个资源服务器根据事务与所述多个应用服务器操作以访问数据，
其中所述多个应用服务器、多个资源服务器和事务日志服务器通过经由网络连接的多个硬件设备实现，以及
其中如果所述多个应用服务器中的应用服务器变为故障应用服务器，则有效应用服务器承担之前由所述故障应用服务器访问的共享事务日志的部分的责任。
10.如权利要求9所述的计算机实现的方法，其中所述共享事务日志包括多个逻辑事务日志，其中所述多个逻辑事务日志中的每一个与所述多个应用服务器中相应的一个应用服务器以及相应的运行标识符相关联。
11.如权利要求9所述的计算机实现的方法，其中所述多个应用服务器中的应用服务器包括：
未决事务列表，其存储多个未决事务；
未决事务列表处理器，其访问所述共享事务日志以及所述未决事务列表。
12.如权利要求9所述的计算机实现的方法，其中所述多个应用服务器中的应用服务器包括：
待删除牺牲者列表，其存储要从所述共享事务日志中删除的条目；
事务管理器，其在所述事务管理器已经完成了完成的事务时，将所述完成的事务从所述共享事务日志添加到所述待删除牺牲者列表，并且在所述待删除牺牲者列表达到定义的大小时，将所述待删除牺牲者列表中的条目从所述共享事务日志中删除。
13.如权利要求9所述的计算机实现的方法，其中所述多个应用服务器中的应用服务器包括：
事务管理器，其对所述共享事务日志执行分组更新。
14.一种记录在多个有形存储介质上的计算机程序，包括：
由事务日志服务器存储的共享事务日志；
由多个应用服务器存储的分布式事务应用，所述分布式事务应用在执行事务时访问所述共享事务日志；以及
由多个资源服务器存储的数据，由所述分布式应用根据事务访问所述数据，
其中所述多个应用服务器、多个资源服务器和事务日志服务器通过经由网络连接的多个硬件设备实现，以及
其中如果所述多个应用服务器中的应用服务器变为故障应用服务器，则有效应用服务器承担之前由所述故障应用服务器访问的共享事务日志的部分的责任。
15.如权利要求14所述的计算机程序，其中所述共享事务日志包括多个逻辑事务日志，其中所述多个逻辑事务日志中的每一个与所述多个应用服务器中相应的一个应用服务器以及相应的运行标识符相关联。
16.如权利要求14所述的计算机程序，其中所述多个应用服务器中的应用服务器包括：
未决事务列表，其存储多个未决事务；
未决事务列表处理器，其访问所述共享事务日志以及所述未决事务列表。
17.如权利要求14所述的计算机程序，其中所述多个应用服务器中的应用服务器包括：
待删除牺牲者列表，其存储要从所述共享事务日志中删除的条目；
事务管理器，其在所述事务管理器已经完成了完成的事务时，将所述完成的事务从所述共享事务日志添加到所述待删除牺牲者列表，并且在所述待删除牺牲者列表达到定义的大小时，将所述待删除牺牲者列表中的条目从所述共享事务日志中删除。
18.如权利要求14所述的计算机程序，其中所述多个应用服务器中的应用服务器包括：
事务管理器，其对所述共享事务日志执行分组更新。
CN200910266025A 2008-12-31 2009-12-31 分布式事务恢复系统和方法 Pending CN101853186A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/347,545 2008-12-31
US12/347,545 US9417977B2 (en) 2008-12-31 2008-12-31 Distributed transactional recovery system and method

Publications (1)

Publication Number Publication Date
CN101853186A true CN101853186A (zh) 2010-10-06

Family

ID=41055161

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200910266025A Pending CN101853186A (zh) 2008-12-31 2009-12-31 分布式事务恢复系统和方法

Country Status (4)

Country Link
US (1) US9417977B2 (zh)
EP (1) EP2207096A1 (zh)
JP (1) JP5296615B2 (zh)
CN (1) CN101853186A (zh)

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102203779A (zh) * 2011-05-03 2011-09-28 华为技术有限公司 更新数据的方法和控制装置
CN103685459A (zh) * 2012-09-24 2014-03-26 日本电气株式会社 分布式系统、服务器计算机、分布式管理服务器和故障防止方法
CN104793998A (zh) * 2014-01-20 2015-07-22 中兴通讯股份有限公司 终端系统资源管理方法及装置
CN105045917A (zh) * 2015-08-20 2015-11-11 北京百度网讯科技有限公司 一种基于实例的分布式数据恢复方法和装置
WO2016074472A1 (zh) * 2014-11-12 2016-05-19 华为技术有限公司 分布式事务资源执行的方法、装置和系统
CN105610917A (zh) * 2015-12-22 2016-05-25 腾讯科技（深圳）有限公司 实现系统中同步数据修复的方法及系统
CN103678570B (zh) * 2013-12-10 2016-06-01 中国人民解放军理工大学 云环境下日志文件的多级别存储与恢复方法及系统
CN105843686A (zh) * 2016-03-29 2016-08-10 乐视控股（北京）有限公司 单例组件资源释放方法及装置
CN105900073A (zh) * 2013-08-29 2016-08-24 慧与发展有限责任合伙企业 分离存储事务日志
CN106033562A (zh) * 2015-03-16 2016-10-19 阿里巴巴集团控股有限公司 事务处理方法、事务参与节点及事务协调节点
CN103782574B (zh) * 2011-09-09 2017-05-10 甲骨文国际公司 用于数据库事务的幂等性
US9898376B2 (en) 2014-04-24 2018-02-20 International Business Machines Corporation Recovery of a transaction after XA end
US9983952B2 (en) 2014-12-22 2018-05-29 International Business Machines Corporation Recovery of local resource
CN108108119A (zh) * 2016-11-25 2018-06-01 中兴通讯股份有限公司 一种可扩展的存储集群事物的配置方法及装置
US10157110B2 (en) 2012-09-24 2018-12-18 Nec Corporation Distributed system, server computer, distributed management server, and failure prevention method
CN109324925A (zh) * 2018-08-29 2019-02-12 北京仁科互动网络技术有限公司 分布式框架的事务处理方法及装置
CN109388481A (zh) * 2018-09-21 2019-02-26 网易（杭州）网络有限公司 一种事务信息的传输方法、系统、装置、计算设备和介质
CN109496406A (zh) * 2018-07-27 2019-03-19 袁振南 基于区块链系统的节点管理方法、装置和存储介质
CN109496407A (zh) * 2018-07-27 2019-03-19 袁振南 区块链系统中的消息传输方法、装置及存储介质
CN111414266A (zh) * 2020-03-23 2020-07-14 山东浪潮通软信息科技有限公司 一种分布式事务的同步异步通信方法和装置

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2135161B1 (en) * 2006-12-29 2015-05-20 Sap Se Management of data for installation on a remote device
US9165025B2 (en) * 2009-12-11 2015-10-20 International Business Machines Corporation Transaction recovery in a transaction processing computer system employing multiple transaction managers
CN101937711B (zh) * 2010-09-21 2013-03-13 深圳市华力特电气股份有限公司 一种数据存储方法及系统
US9026493B1 (en) * 2011-02-28 2015-05-05 Google Inc. Multi-master RDBMS improvements for distributed computing environment
US10127259B2 (en) * 2011-09-29 2018-11-13 Oracle International Corporation System and method for database persistence of transaction logs
US20130097136A1 (en) * 2011-10-17 2013-04-18 Pie Digital, Inc. Method and system for acessing domain specific in-memory database management system
US9069704B2 (en) * 2011-11-07 2015-06-30 Sap Se Database log replay parallelization
US9146944B2 (en) 2012-03-16 2015-09-29 Oracle International Corporation Systems and methods for supporting transaction recovery based on a strict ordering of two-phase commit calls
US9760584B2 (en) * 2012-03-16 2017-09-12 Oracle International Corporation Systems and methods for supporting inline delegation of middle-tier transaction logs to database
US10133596B2 (en) 2012-03-16 2018-11-20 Oracle International Corporation System and method for supporting application interoperation in a transactional middleware environment
US10496977B2 (en) 2012-07-16 2019-12-03 Square, Inc. Storing and forwarding payment transactions
CN103716174A (zh) * 2012-10-09 2014-04-09 鸿富锦精密工业（深圳）有限公司 测试日志撷取系统及方法
WO2014082663A1 (en) * 2012-11-28 2014-06-05 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for managing distributed transactions
US9911110B2 (en) * 2013-03-05 2018-03-06 Square, Inc. Predicting approval of transactions
US20150019620A1 (en) * 2013-07-09 2015-01-15 Kaminario Technologies Ltd. High availability for communications based on remote procedure calls
US9830234B2 (en) * 2013-08-26 2017-11-28 Vmware, Inc. Distributed transaction log
US9715405B2 (en) * 2013-09-23 2017-07-25 International Business Machines Corporation Efficient coordination across distributed computing systems
US10191765B2 (en) 2013-11-22 2019-01-29 Sap Se Transaction commit operations with thread decoupling and grouping of I/O requests
US10015049B2 (en) 2014-02-13 2018-07-03 Sap Se Configuration of network devices in a network
CN105404579B (zh) * 2014-09-11 2018-06-29 阿里巴巴集团控股有限公司 平台化日志分析的计算方法及装置
CN107430606B (zh) * 2014-12-01 2021-06-29 信息科学有限责任公司 具有并行持久性的消息代理系统
GB2533403A (en) 2014-12-19 2016-06-22 Ibm Data repository for a distributed processing environment
CN107229455B (zh) 2016-03-24 2019-09-17 阿里巴巴集团控股有限公司 一种业务处理方法、装置及系统
US10366378B1 (en) 2016-06-30 2019-07-30 Square, Inc. Processing transactions in offline mode
US10922307B2 (en) 2017-12-11 2021-02-16 NextWorld, LLC Automated transaction engine
US10942823B2 (en) * 2018-01-29 2021-03-09 Guy Pardon Transaction processing system, recovery subsystem and method for operating a recovery subsystem
US10983876B2 (en) * 2018-03-29 2021-04-20 Seagate Technology Llc Node management of pending and unstable operations
US11561999B2 (en) * 2019-01-31 2023-01-24 Rubrik, Inc. Database recovery time objective optimization with synthetic snapshots
US11409618B2 (en) 2020-09-14 2022-08-09 International Business Machines Corporation Transaction recovery
US11573876B2 (en) * 2020-10-30 2023-02-07 Google Llc Scalable exactly-once data processing using transactional streaming writes
US20220253409A1 (en) * 2021-02-05 2022-08-11 International Business Machines Corporation Cleaning compensated change records in transaction logs
KR20220160898A (ko) * 2021-05-28 2022-12-06 삼성에스디에스 주식회사 트랜잭션 처리 방법 및 장치
US11550672B1 (en) 2021-09-09 2023-01-10 Kyndryl, Inc. Machine learning to predict container failure for data transactions in distributed computing environment
JP7284791B2 (ja) * 2021-09-22 2023-05-31 株式会社日立製作所 分散トランザクションシステム及び分散トランザクションシステムにおける分散トランザクション処理方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63156258A (ja) * 1986-12-19 1988-06-29 Fujitsu Ltd トランザクシヨンログ処理方式
JPH04199339A (ja) * 1990-11-29 1992-07-20 Hitachi Ltd 分散処理システムの分散トランザクションファイル制御方法
JPH07244645A (ja) * 1994-03-04 1995-09-19 Mitsubishi Electric Corp 高信頼分散トランザクション処理システム
JPH08286964A (ja) * 1995-04-13 1996-11-01 Mitsubishi Electric Corp 分散トランザクション処理方法
US6944785B2 (en) 2001-07-23 2005-09-13 Network Appliance, Inc. High-availability cluster virtual server system
AU2003216238A1 (en) 2002-02-22 2003-09-09 Bea Systems, Inc Highly available transaction recovery for transaction processing systems
JP2003345639A (ja) * 2002-05-27 2003-12-05 Nec Soft Ltd データベースの交換システム
US7096333B2 (en) * 2002-07-18 2006-08-22 International Business Machines Corporation Limited concurrent host access in a logical volume management data storage environment
WO2004104739A2 (en) * 2003-05-14 2004-12-02 Rhysome, Inc. Method and system for reducing information latency in a business enterprise
US7831782B1 (en) * 2004-06-30 2010-11-09 Symantec Operating Corporation Roll-back log to provide data consistency
US7444538B2 (en) 2004-09-21 2008-10-28 International Business Machines Corporation Fail-over cluster with load-balancing capability
US7403945B2 (en) * 2004-11-01 2008-07-22 Sybase, Inc. Distributed database system providing data and space management methodology
JP2007058506A (ja) * 2005-08-24 2007-03-08 Ricoh Co Ltd 文書管理サーバ、文書管理システム、及び、文書管理プログラムとその記録媒体
US20070174695A1 (en) * 2006-01-18 2007-07-26 Srinidhi Varadarajan Log-based rollback-recovery

Cited By (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011120452A2 (zh) * 2011-05-03 2011-10-06 华为技术有限公司 更新数据的方法和控制装置
WO2011120452A3 (zh) * 2011-05-03 2012-03-08 华为技术有限公司 更新数据的方法和控制装置
CN102203779B (zh) * 2011-05-03 2013-04-17 华为技术有限公司 更新数据的方法和控制装置
CN102203779A (zh) * 2011-05-03 2011-09-28 华为技术有限公司 更新数据的方法和控制装置
CN103782574B (zh) * 2011-09-09 2017-05-10 甲骨文国际公司 用于数据库事务的幂等性
CN107070919B (zh) * 2011-09-09 2020-06-26 甲骨文国际公司 用于数据库事务的幂等性
CN107070919A (zh) * 2011-09-09 2017-08-18 甲骨文国际公司 用于数据库事务的幂等性
US10157110B2 (en) 2012-09-24 2018-12-18 Nec Corporation Distributed system, server computer, distributed management server, and failure prevention method
CN103685459A (zh) * 2012-09-24 2014-03-26 日本电气株式会社 分布式系统、服务器计算机、分布式管理服务器和故障防止方法
CN103685459B (zh) * 2012-09-24 2017-07-28 日本电气株式会社 分布式系统、服务器计算机、分布式管理服务器和故障防止方法
CN105900073B (zh) * 2013-08-29 2020-04-10 慧与发展有限责任合伙企业 用于维护事务日志的系统、计算机可读介质和方法
US10140174B2 (en) 2013-08-29 2018-11-27 Hewlett Packard Enterprise Development Lp Separating storage transaction logs
CN105900073A (zh) * 2013-08-29 2016-08-24 慧与发展有限责任合伙企业 分离存储事务日志
CN103678570B (zh) * 2013-12-10 2016-06-01 中国人民解放军理工大学 云环境下日志文件的多级别存储与恢复方法及系统
CN104793998B (zh) * 2014-01-20 2019-04-16 中兴通讯股份有限公司 终端系统资源管理方法及装置
CN104793998A (zh) * 2014-01-20 2015-07-22 中兴通讯股份有限公司 终端系统资源管理方法及装置
US9898376B2 (en) 2014-04-24 2018-02-20 International Business Machines Corporation Recovery of a transaction after XA end
WO2016074472A1 (zh) * 2014-11-12 2016-05-19 华为技术有限公司 分布式事务资源执行的方法、装置和系统
US11368520B2 (en) 2014-11-12 2022-06-21 Huawei Cloud Computing Technologies Co., Ltd. Method, apparatus, and system for executing distributed transaction resources
US10771535B2 (en) 2014-11-12 2020-09-08 Huawei Technologies Co., Ltd. Method, apparatus, and system for executing distributed transaction resources
US10326828B2 (en) 2014-11-12 2019-06-18 Huawei Technologies Co., Ltd. Method, apparatus, and system for executing distributed transaction resources
US9983952B2 (en) 2014-12-22 2018-05-29 International Business Machines Corporation Recovery of local resource
US10733065B2 (en) 2014-12-22 2020-08-04 International Business Machines Corporation Recovery of local resource
CN106033562B (zh) * 2015-03-16 2019-12-06 阿里巴巴集团控股有限公司 事务处理方法、事务参与节点及事务协调节点
CN106033562A (zh) * 2015-03-16 2016-10-19 阿里巴巴集团控股有限公司 事务处理方法、事务参与节点及事务协调节点
CN105045917A (zh) * 2015-08-20 2015-11-11 北京百度网讯科技有限公司 一种基于实例的分布式数据恢复方法和装置
WO2017028394A1 (zh) * 2015-08-20 2017-02-23 北京百度网讯科技有限公司 一种基于实例的分布式数据恢复方法和装置
US10783163B2 (en) 2015-08-20 2020-09-22 Beijing Baidu Netcom Science And Technology Co., Ltd. Instance-based distributed data recovery method and apparatus
CN105045917B (zh) * 2015-08-20 2019-06-18 北京百度网讯科技有限公司 一种基于实例的分布式数据恢复方法和装置
CN105610917B (zh) * 2015-12-22 2019-12-20 腾讯科技（深圳）有限公司 实现系统中同步数据修复的方法及系统
CN105610917A (zh) * 2015-12-22 2016-05-25 腾讯科技（深圳）有限公司 实现系统中同步数据修复的方法及系统
CN105843686A (zh) * 2016-03-29 2016-08-10 乐视控股（北京）有限公司 单例组件资源释放方法及装置
CN108108119A (zh) * 2016-11-25 2018-06-01 中兴通讯股份有限公司 一种可扩展的存储集群事物的配置方法及装置
CN108108119B (zh) * 2016-11-25 2023-03-24 中兴通讯股份有限公司 一种可扩展的存储集群事物的配置方法及装置
CN109496407A (zh) * 2018-07-27 2019-03-19 袁振南 区块链系统中的消息传输方法、装置及存储介质
WO2020019343A1 (zh) * 2018-07-27 2020-01-30 袁振南 区块链系统中的消息传输方法、装置及存储介质
CN109496406A (zh) * 2018-07-27 2019-03-19 袁振南 基于区块链系统的节点管理方法、装置和存储介质
CN109496407B (zh) * 2018-07-27 2020-07-24 袁振南 区块链系统中的消息传输方法、装置及存储介质
CN109324925A (zh) * 2018-08-29 2019-02-12 北京仁科互动网络技术有限公司 分布式框架的事务处理方法及装置
CN109388481A (zh) * 2018-09-21 2019-02-26 网易（杭州）网络有限公司 一种事务信息的传输方法、系统、装置、计算设备和介质
CN111414266A (zh) * 2020-03-23 2020-07-14 山东浪潮通软信息科技有限公司 一种分布式事务的同步异步通信方法和装置
CN111414266B (zh) * 2020-03-23 2024-04-05 浪潮通用软件有限公司 一种分布式事务的同步异步通信方法和装置

Also Published As

Publication number Publication date
JP5296615B2 (ja) 2013-09-25
EP2207096A1 (en) 2010-07-14
US20100169284A1 (en) 2010-07-01
JP2010157202A (ja) 2010-07-15
US9417977B2 (en) 2016-08-16

Similar Documents

Publication Publication Date Title
CN101853186A (zh) 分布式事务恢复系统和方法
US11899684B2 (en) System and method for maintaining a master replica for reads and writes in a data store
CN103782574B (zh) 用于数据库事务的幂等性
US9317372B1 (en) Dynamic membership management in a distributed system
US7730489B1 (en) Horizontally scalable and reliable distributed transaction management in a clustered application server environment
CN101243445B (zh) 数据变更通告
JP2022515949A (ja) トランザクション処理方法、装置、機器並びにコンピュータプログラム
US10248704B2 (en) System and method for log conflict detection and resolution in a data store
US7480816B1 (en) Failure chain detection and recovery in a group of cooperating systems
CN103500180A (zh) 一种基于连接池管理的分布式事务处理方法
US6381617B1 (en) Multiple database client transparency system and method therefor
JP2014522513A (ja) マルチサーバ予約システムにおける同期化メカニズムのための方法及びシステム
CN108701157A (zh) 分布式事务处理系统中有保证的提交结果
US20030065971A1 (en) System-managed duplexing of coupling facility structures
WO2023082992A1 (zh) 数据处理方法以及系统
Hu et al. Transactional mobility in distributed content-based publish/subscribe systems
US11522966B2 (en) Methods, devices and systems for non-disruptive upgrades to a replicated state machine in a distributed computing environment
CN112069160B (zh) 一种基于cap数据清洗同步方法
CN101488134A (zh) 数据库系统的复制环境内的高性能修改事务的方法及系统
Barnes et al. Logging last resource optimization for distributed transactions in Oracle WebLogic server
Kumar et al. Design and implementation of Three Phase Commit Protocol (3PC) algorithm
Abreu et al. Recovery in CloudDBAppliance's High-availability Middleware.
Design HP Reliable Transaction Router Application Design Guide
Najafzadeh et al. Improving the scalability of geo-replication with reservations
Schelfaut Distributed systems (H04I4A)-summary (version 1)

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C53 Correction of patent for invention or patent application
CB02 Change of applicant information

Address after: German Waldo

Applicant after: SAP AG

Address before: German Waldo

Applicant before: SAP AG

COR Change of bibliographic data

Free format text: CORRECT: APPLICANT; FROM: SAP AG TO: SAP EUROPE AG

C12 Rejection of a patent application after its publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20101006