专利名称：分布式事务恢复系统和方法
技术领域：
本发明涉及事务可恢复性(transactional recoverability)，具体地，涉及分布 式计算环境中的事务可恢复性。
背景技术：
除非在此另外指示，否则在本部分中描述的方法不是本申请权利要求的现有技 术，并且不因包括在本部分中而承认其为现有技术。在目前的许多商业企业中，企业应用正借助企业内部或外部存在的许多分布式资 源。这些资源可以是数据库、消息传递系统或者甚至可以是向外部世界提供服务的应用。在许多情况下，期望以事务的方式进行遍及这种系统的更新。这基本意味着所述 更新必须符合ACID准则(原子性(atomicity)、一致性、隔离性和持续性)。原子性意味着 分布式资源中的改变在所有资源都执行或都不执行。一致性意味着当事务结束时，在这些 资源之间的完整性约束必须有效。隔离性意味着事务外部的任何操作都看不到中间状态。 持续性意味着如果事务成功结束，则它将持续并且不被撤销。目前，在企业内常见的几乎所有资源都符合这些准则。如果要求数据库管理系统 (DBMS)在单个事务(transaction)中从一个账户取钱并且存入另一账户，那么可以预期该 DBMS能够根据上述ACID规则完美地完成这一事务。该DBMS本身对该事务进行完全地控 制，它既是事务管理器，也是被事务管理器管理的资源。如果事务必须跨越多个资源，则情况完全改变。应用服务器变为事务管理器，而所 有资源变为该事务管理器的下级(subordinate)。因为事务的整体状态现在分布在所有涉 及到的资源管理器上，所以将存在一些时间量，在所述时间量期间整个事务不一致。所述不一致性不是可以避免的事情，它存在于分布式系统的基本性质中。因此如 果执行事务工作或其部分的系统崩溃，则该不一致性将持续。这种情况的一个例子可以是， 在一个资源已经进行了它的改变而第二个资源还没有进行改变时，应用服务器崩溃。为了克服这些问题，可以使用事务恢复(transaction recovery)策略。如果在事 务中涉及的系统再次变为可用，则应用服务器中的事务恢复功能会记起向触发该事务的应 用承诺过什么。应用服务器与资源检查它们那部分事务的结果，并试图达到一致状态。如果 应用服务器不能达到一致状态，则它将所涉及的资源之间的这种不一致性通知给操作者， 从而至少标识出问题。如果在没有事务可恢复功能的情况下使用分布式事务，则客户数据极有可能 会被损坏。这就是利用当前的Java 应用服务器架构的情况。如在JavaTransaction Processing (Java事务处理)一书中所描述的“一些应用服务器(目前这主要应用于实 验性项目或开源项目，而没有应用于企业级质量服务器)不提供恢复能力，这些应用服务 器不应当用于与要求事务的多个可恢复资源交互的应用”。见Mark Little等人的Java Transaction Processing(PrenticeHall PTR 2004)。实现事务恢复是对应用服务器的根本改变。可以创建并使用新的恢复功能。此外，可以改变实现资源的方式。这可能需要对其他系统进行进一步地修改，所述其它系统例如 服务器内的Java 消息传递系统提供者(JavaTMMeSSaging System(JMS)provider)、事务管 理器(Transaction Manager, TM)、JDBC (Java Database Connectivity, Java 数据库连 接)DB (数据库)池服务、以及Java连接器容器(Java Connector Container) 0如果应用服务器和事务管理器(其曾是应用服务器的一部分)一起崩溃，则在事 务中曾涉及的资源被单独留下。这种单独的资源是危险的，因为仍然存在未决的(pending) 事务在一段时间后，该资源将会决定是提交(commit)还是回滚(rollback)它所涉及的事 务部分。这一决定可能符合也可能不符合事务管理器的原始意图——这就是所谓的启发式 决定(heuristic decision)。因此，只要可能就必须避免启发式决定。分布式计算环境通常包括多个层，其中每层具有一个或多个计算设备。例如，两层 架构可以包括客户端层和服务器层，在每层中具有多个客户端设备和多个服务器设备。三 层架构可以包括客户端层、应用服务器层和数据库服务器层(同样，在每层中具有多个计 算设备)。应用服务器层也可以被称为应用服务器集群(application server cluster) 0 应用服务器集群可以由许多服务器节点组成，这些服务器节点可以遍及分布式资源执行事 务。应用服务器可以实现诸如Java 企业版(Java EnterpriseEdition) .Microsoft. NET 环境等的计算环境。数据库服务器层也可以称为资源层。存在于应用服务器上的应用可以以事务的方 式(transactional manner)使用(资源层的)不同资源。资源的例子有数据库系统、消息 传递系统和企业信息系统。应用服务器中控制事务的部分被称为事务管理器(TM)。TM用来安排 (orchestrate)遍及这些分布式资源的事务的语义学(semantics)可以通过来自国际标准 化组织 Open Group 的 DTP (Distributed Transaction Processing,分布式事务处理)XA 规 范来描述。TM代表存在于服务器上的应用管理事务。这意味着它负责将所有资源保持在一致 状态。由于事务的整体状态分布在所有涉及的资源管理器上，所以将存在一些时间量，在所 述时间量期间整个事务不一致。所述不一致性是不可避免的——它存在于分布式系统的基本性质中。因此如果执 行事务工作(或其部分)的系统崩溃，则该不一致性将持续。这种情况的一个例子是，在一 个资源已经进行了它的改变而第二个资源还没有时，应用服务器节点崩溃。如果一个或多 个应用服务器节点崩溃，则分布式事务可能保持在未完成状态。由于这种事务的每一个参与者都可能崩溃，因此每一个参与者有必要将其提 交或回滚的决定写到持久存储器(persistent store)中。该存储器被称为事务日志 (Transaction Log，TL0G)0可以根据Open Group的DTP XA规范进行事务处理。该规范将事务的完成划分为 两个阶段准备阶段和提交阶段。下面描述具有两个参与者的事务完成过程。资源1利用资源适配器1连接到应用 服务器，资源2利用资源适配器2连接到应用服务器。每个参与者都具有它自己的TL0G。 因此，总共存在三个TL0G —个由TM维护，另两个由它们各自的资源管理器控制。
事务完成过程如下1.应用要求应用服务器提交事务。2.应用服务器通知TM应当完成的事务。3. TM启动事务完成的第一阶段它要求第一资源管理(RM)准备事务。4.假设第一 RM能够提交并且将该意图写到它自己的事务日志中。该第一 RM从准 备调用(pr印are call)返回，用信令通知TM成功。5.对第二 RM执行同样的过程。6.由于我们假设TM只接收到成功的准备返回代码，因此它决定提交全部事务。TM 在其联系RM之前将其提交的决定写入它自己的TL0G。在写操作后，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处理器的操作之前，提
8供一些背景。图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按照Java 企业版环境操作。例如，客户端计算 机112可以实现网页浏览器，其与应用服务器114交换Java 格式的信息。应用服务器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还可 以称为TL0G130。应用服务器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，，期间产生的未 决事务的情况。因此，所述情况为“&:乂1)、13:13(1)、(^(1)、(1:(1(1)”。假设节点a崩溃并且具有一些未决事务。任何剩余节点都能够接管这些事务。我 们假设节点b是最快的。因此，现在情况为“b:b(l)+a(l)、C:C(l)、d:d(l)”。现在假设节点b崩溃。同样，节点c和节点d竞争。可能并且非常有可能节点c和节 点d将仅仅部分地接管节点b曾试图解决的未决事务。一个可能的结果是，“c:c(l)+b(l)、 d:d(l)+a(l) ”。如果节点a再次出现，则节点a不需要关心来自它较早的运行的事务。这是因 为很可能某个其他节点已经关照了那些事务。因此，情况将是“a:a(2)、c:c(l)+b(l)、 d:d(l)+a(l) ”。结果，TL0G可以在逻辑上被分段为不同的部分，这些不同的部分可以具有不同 的拥有者。因为我们允许将文件系统或DBMS用作用于TL0G的底层持久层(underlying persistence layer)，所以这可以通过两种选项来实现。一种选项是基于文件系统的TLOG。 节点的每次启动创建新的物理文件。该文件系统可以在各节点之间共享，以使得节点可以 接管另一节点的TL0G。另一选项是基于DBMS的TL0G。对于所有节点可以只存在一组共享 表。数据库方案允许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_l 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)、事务日志(TL0G)、未决事务列表(PTL)和PTL处理器(PP)。(例如，见 图3。)事务管理器(例如，图3中的132a)可以实现为来自SAP AG的NetWeaverJava服 务器的一部分。TM协调事务。根据实施例，TM是多线程的，这意味着事务总是在应用的线 程中开始。如果TM决定提交事务，则它将用于该事务的条目写入持久事务日志(TL0G)。这 在对任何所涉及的资源管理器(冊)执行任何提交调用之前发生。因此，TM记录它的提交 的意图，而不是任何提交操作的结果。如果在TL0G中不存在用于事务的条目，则意味着TM决定回滚(RB)该事务。根 据实施例，这种更新TL0G的方式可以按照“假定终止”(Presumed-Abort)策略来执行。见 Weikum 禾口 Vossum 的 Transactionlnformation System (事务信息系统)，第 19 章，分布式 事务恢复(Academic Press2002)。一些错误状况使得TM不可能将两阶段提交事务立即带入一致状态。对于这些 情况的详细描述，请阅读下面关于资源管理器错误的部分。在这种情况下，TM不再阻挡 (block)应用线程，而是将事务移交到未决事务列表(PTL)。TL0G(例如，图3中的320a)存储TM提交事务的决定。可以存储在系统DBMS或文 件系统中。根据实施例，对于TM的每次启动，都会创建新的逻辑TL0G。在文件系统中，这可 能导致许多物理TL0G。根据实施例，PTL(例如，图3中的308a)是存储器内的结构。它包含由于一个或 多个所涉及的RM有问题(例如，故障)所以目前不能被解决的事务。PTL中的条目可以意 味着事务必须被提交，或者事务必须被回滚。另外，每个条目跟踪每个事务分支的状态—— 因此，总是清楚哪个RM返回了什么结果以及哪个RM直到现在仍不能被成功联系到。PTL处理器(例如，图3中的134a)试图解决PTL中的事务。它通过针对PTL中 的所有条目进行循环来试图解决PTL中的事务。PTL处理器和TM以相同的方式处理事务。 这意味着稍后描述的所有冊错误处理对于TM和PP是完全相同的。唯一的差别是，PTL处 理在它自己的线程中发生，而不是在应用请求的线程中发生。PP还可能从外部事务日志读入事务。因此，PTL可以包含指向许多TL0G的条目。2.事务管理器事务管理器必须处理在2PC协议的不同阶段期间资源管理器(RM)可以提供的复 杂的返回代码。在下述实施例中会增加额外的复杂度在所述实施例中，实现XA资源接口 的不同资源管理器可能对于在特定情况下应该选择哪个返回代码具有不同的解释。此外，围绕事务的不同规范有时候是模糊的或者不完整的。为了解决该问题，在一个实施例中，如果遇到返回代码，该实施例将正式的开发组 XA规范(Open Group XA Specification)实现为解释的源。这意味着(根据实施例)TM 甚至会处理在JSR-000907 Java 事务API规范中没有提到、而仅仅在Open Group XA规 范中提到的返回代码。即使这些返回代码在Java 文献中没有提到，我们预期它们也会在 真实世界中发生，因为一些Java 资源管理器仅仅是围绕现有C/C++资源管理器实现的瘦 Java ^^ (thin Java wrapper)。2. 1准备阶段之前的资源管理器错误在准备阶段之前，错误处理不像准备之后那样复杂。可以预期，即使所有涉及的各 方失去了相互联系，它们也可以回滚它们的事务部分，从而不一致性应当只存在相对短的 时间。尽管如此，也需要密切关注在该阶段期间JTAXAReS0Urce(XA资源)接口的不同操 作Operation start (Xid xid, int flags) (女台(Xid xid, int flags))根据实施例，连接应当总是指向(pinned to)事务。因此，所使用的标志的唯一值 是TMN0FLAGS。根据替代实施例，连接可以利用end (TMSUSPEND)和start (TMJ0IN)来中止 (suspend)和继续(resume)。这将导致使用较少的连接，但是可能具有负面的性能影响。附 加的风险是，一些冊可能不能实现适当的事务中止机制。Operation :end(Xid xid, int flags)(操作结束(Xid xid, int flags))根据实施例，只使用TMSUCCESS。根据替代实施例，如果TM决定回滚，则优化方式 将是调用end(TMFAIL)。这将节约针对所涉及的RM的附加的回滚调用。由于不清楚是否所 有的RM都支持这一优化方式，并且因为只有低比例的事务将被回滚，所以该替代实施例在 一些实现中可能是不理想的。如果返回代码是除XA_0K之外的任何代码，则全部事务将被回滚。(更精确地讲， 在Java中除XA_0K之外的XA返回代码都被翻译为异常)。如果返回代码是XA_RB*，则全 部事务将被回滚，而不是在返回该代码的RM处发出回滚调用。Operation prepare (Xid xid)(操作准备(Xid, xid)根据实施例，如果RM返回RD0NLY，则立即将该RM从事务中排除。不将用于该分支 的条目写入TL0G。RD0NLY结果既不是提交的投票也不是回滚的投票。如果返回XA_RB*，则事务将被回滚，但是将不会针对这些特定的RM调用回滚。它 们投票赞成回滚并且已经执行了回滚。如果所有准备调用都成功，则TM决定提交事务。Operation :commit (Xid xid, boolean onePhase)(操作提交(Xid xid, boolean onePhase))根据实施例，如果onePhase被设置为真，则将事务当作本地事务。因此，不写入 TL0G。如果onePhase被设置为假，则2PC事务完全失败，并且具有非常复杂的错误结果。下 面各部分将更详细地描述将如何对待这些可能的错误。2. 2在提交阶段期间的资源管理器错误根据实施例，在提交阶段，TM调用在事务中参与的所有RM，并且要求它们提交。根 据实施例，这以顺序方式而不是并行方式进行。根据替代实施例，可以使用并行方法来获得 更短的事务等待时间，但是并行方法伴随有用于同步不同RM提交返回结果的额外开销。在TM架构背后的一个值得注意的方面是，要达到最大事务吞吐量而不是最小事务等待时间。图5是根据本发明实施例的、图示在所有RM都已经成功准备时的时间点的活动图 的流程图500。TM决定提交事务并且随后针对每个参与的RM调用提交。假设RM不能履行 它在准备阶段做出的承诺，并且没有返回XA_0K给TM。取决于RM提供的特定错误代码，将 采取不同的动作。TM针对参与事务的每个RM进行循环，因此图5中描述的执行流程将适用 于每个RM。有时候，图5示出了针对RM调用忽略(forget)方法。根据实施例，这不是立即 发生，而是在全部事务结束后发生。在步骤501，如果XA_RB*或XA_RMERR为真，则处理进行到步骤502 ；如果不是，则 处理进行到步骤506。XA_RB*代表一整类的返回代码XA_RBR0LLBACK、XA_RBC0MMFAIL、 XA_RBDEADL0CK、XA_RBINTEGRITY、XA_RB0THER、XA_RBPR0T0、XA_RBTIME0UT 以及 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决定回滚事务。不向TL0G写入有关TM这一想法改变的更新。这 听起来可能令人惊讶，因为在TL0G中已经存在表示TM决定提交的条目。但是即使在尝试 回滚期间发生崩溃，PTL处理器也将做出与TM相同的事情，因为它实现与TM相同的逻辑。 这意味着PTL处理器将在TL0G中找到该事务。它将会试图提交该事务，发现第一 RM回滚， 这将导致回滚全部事务的决定。处理然后进行到步骤505。在步骤504，TM确定知道不是第一事务分支的一个事务分支被回滚。因此，存在 启发式混合情况(heuristic mixed situation)——其含义是TM确定知道事务不一致。 TM试图提交其他RM。TM可以向管理员报告严重(Severe)错误，并且可以抛出(throw) HeuristicMixedException。在步骤505，因为现在整个事务被标记为回滚，所以TM将回滚在事务中参与 的所有冊。管理员只获得警告(warning)，因为事务仍然是一致的。最后，TM将抛出 RollBackException。在步骤506，如果XA_HEURRB为真，则处理进行到步骤507 ；如果不是，则处理进行 到步骤514。对于XA_HEURRB，XA规范说明如下“由于启发式决定，已进行的代表指定事务分 支的工作被回滚”。这完全等同于步骤501的情形，除了在这种情况中，即使该事务结束，RM也将记住(remenber)该事务，除非在步骤511中RM被允许忽略该事务。作为xa_commit函 数的一部分，XA规范规定“如果资源管理器已经启发式地完成了与、id相关联的工作，则 该函数仅仅报告资源管理器如何完成该事务分支。在事务管理器调用Xa_f0rget()之前， 资源管理器不能忽略以启发式方式完成的分支”。步骤507-510分别类似于步骤502-505，除了处理从步骤509和510进行到步骤 511。在步骤511中，只要调用Xa_f0rget ()不是可配置的，处理就进行到步骤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) 0作为整体事务现在被启发式地混 合——因此，我们试图提交其它RM并且抛出HeuristicMixedExc印tion。之后，如同XA_ HEURRB情况那样(步骤511等)，我们继续进行相同的XA忽略逻辑。在步骤516，如果XA_HEURHAZ为真，则处理进行到步骤517，否则处理进行到步骤 518。在步骤517，如果遇到启发式危险(heuristic hazard)情形，则RM不知道事务分 支的状态。这可能是暂时的情形或永久的情形。根据实施例，将XA_HEURHAZ当作永久的返回代码。关于异常JTA只知 道 RollbackException, HeuristicMixedException, HeuristicRollbackException, SecurityException, IllegalStateException 禾口 SystemException。 根据实施例， HeuristicMixedException^ SAP ^AWWSAPHeuristicHazardException|j'fjrM,^:)|f^M 出。这使得利用ex.getCauseO捕获到该异常的应用具有作出反应的可能性。根据将XA_HEURHAZ看作是短暂的返回代码的实施例，以提交事务为目的，该事务 将被传送到“未决事务列表”(PTL)。PTL条目还包括关于事务中涉及的不同分支的结果的 信息。PTL处理器将在稍后的时间负责执行PTL。如果拥有这个列表的进程死亡，则该列表 中的该非持久条目也会丢失。这不会导致任何问题，因为PTL处理器将在恢复时在TL0G中 再次找到该事务。因此，该事务不会被忽略。在步骤5 1 8，如果XA_RETRY或XA_RMFAIL为真，则处理进行到步骤519 ；否则处 理进行到步骤520。在步骤519，TM将事务添加到PTL以用于提交，并且将危险状态报告给管理员。
关于XA_RETRY，DTP规范规定“资源管理器此时不能提交事务分支。当阻挡状 况存在并且TMN0WAIT被设置时，可以返回该值。然而注意，即使在TMN0WAIT没被设置 时也可以返回该值(例如，如果当前不能获得必要的稳定存储)。如果在标志中设置了 TM0NEPHASE，则不能返回该值。代表lid所占用的所有资源保持在准备状态，直到可以进 行提交。事务管理器应当在稍后重新发出Xa_COmmit()”。对于XAER_RMFAIL，DTP规范规定“发生错误，使得资源管理器不可用”。概括来说，TM将不再延迟控制线程，并且试图在稍后的时间提交该分支。因 此，将以提交为目的将该分支添加到PTL中。根据实施例，抛出的异常将是对JTA HeuristicMixedExc印tion进行扩展的 SAP私有的 SAPHeuristicHazard Exc印tion。JTA异 常被扩展的原因在于，在可能存在不一致事务(启发式危险)与确实存在不一致事务(启 发式混合)之间存在差别。该差别在XA规范中是可见的，但是在JTA规范中丢失了。在步骤520，如果TM到达这个活动，则表示在事务处理期间一些事情严重出错可 能是RM内的故障、TM内的故障或它们之间的故障。人类管理员可能也已经干预过事务状 态。这里是可能的事情的列表(从DTP XA规范中引用的材料) “ [XAER_N0TA]资源管理器不知道指定的XID”。情况可能是管理员决定手动提交 或回滚该未决事务。 “ [XAER_INVAL]指定了无效的参量(argument) ”。这指向RM或RMXA驱动器内的错误。
“ [XAER_PR0T0]在不适当的上下文中调用了例程”。这指向TM实现中的错误。
“ [XAER_ASYNC]在标志中设置了 TMASYNC，并且已经超过了未完成的异步操作的 最大数目，或者在资源管理器的Xa_SWitch_t结构的标志元素中没有设置TMUSEASYNC”。 Java 不支持异步事务的概念，因此这指向RM或RM XA驱动器中的错误。 如果返回代码是其他内容，则它是DTP XA规范中没有提到的代码。这应该不会 发生。2. 3在回滚阶段期间的资源管理器错误如果在准备阶段期间分支之一投票赞成回滚，则TM将试图回滚全部事务。为此， 根据实施例，TM以顺序的方式针对所有参与的RM进行循环。如果这些RM之一返回错误， 则不会使TM停止继续回滚其它RM。除XA_0K之外的任何返回都被认为是错误——它可能 是XA返回代码或另一个异常。图6是根据本发明实施例的、概述TM将如何处理每个可能的XA返回代码的活动 图的流程图600。在步骤601，如果XA_RB为真，则处理进行到步骤602 ；否则处理进行到步骤603。 XA_RB* 代表一整类的返回代码XA_RBR0LLBACK，XA_RBCOMMIFAIL, XA_RBDEADL0CK, XA_ RBINTEGRITY, XA_RB0THER, XA_RBPR0T0, XA_RBTIME0UT 以及 XA_RBTRANSIENT。在步骤602，对于TM行为而言，详细的XA_RB*原因是无关的。XA规范概括如下 “[XA_RB*]资源管理器已经回滚了事务分支的工作，并且已经释放了所有占用的资源。在 分支已经被标记为只回滚(rollback-only)时一般会返回这些值”。这基本上意味着事务 被回滚，并且RM已经忽略了该事务。如果一些冊在准备期间投票赞成回滚，则这对于它们 而言可能是正常行为。我们将利用警告通知管理员。
在步骤603，如果XA_HEURRB为真，则处理进行到步骤604 ；否则处理进行到步骤 605。在步骤604，尽管TM没有告诉它这样做，但是RM已经进行了启发式地回滚。XA规 范规定“由于启发式决定，所进行的代表指定事务分支的工作被回滚。资源管理器只有在 已经成功准备了、id时才可以返回该值”。因为反正TM也想要回滚，所以这将不会导致事 务的不一致状态。TM抛出HeuristicRollbackExc印tion，并且将该RM的启发式决定通知 给管理员。然后该处理进行到步骤607。在步骤605，如果XA_HEURC0M或XA_HEURMIX为真，则处理进行到步骤606，否则处 理进行到步骤610。在步骤606，对于HEUR_C0M，XA规范规定“由于启发式决定，所进行的代表指定事 务分支的工作被提交。资源管理器只有在已经成功准备了 lid时才可以返回该值”。对于 HEUR_MIX, XA规范规定“由于启发式决定，所进行的代表指定事务分支的工作被部分提交 和部分回滚。资源管理器只有在已经成功准备了 lid时才可以返回该值”。概括来说，事务现在明确处于不一致状态，因此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 只知道 RollbackExc印tion、HeuristicMixedException> HeuristicRollbackException、SecurityException、11legalStateException 禾口 SystemExc印tion。根据实施例，HeuristicMixedException 被 SAP 私有的 SAP HeuristicHazardExc印tion所扩展，并且将其抛出。这使利用ex. getCause ()捕获该异常 的应用具有作出反应的可能性。根据XA_HEURHAZ被认为是短暂返回代码的实施例，以回滚为目的将事务传送到 “未决事务列表”(PTL)。PTL条目还包括关于事务中涉及的不同分支的结果的信息。PTL处 理器将在稍后的时间点负责执行该PTL。如果拥有该列表的进程死亡，则该列表中的该条目 也会丢失。这不会造成任何问题，因为PTL处理器在恢复时将不会在TL0G中发现该事务， 而是将其识别为对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不知道事务分支的结果，这可以被当作是启发式危险情 形。这里，使复杂性增加的是这样的事实冊附加地告诉TM他可能忽略该事务。这意味着 在稍后的时间调用该冊的恢复方法可能不再返回该事务。基本上，这意味着RM打破了它 记住已经准备的事务的承诺。一个实施例不对此执行特殊的逻辑。如果RM忽略它的事务，则TM对此无能为力。 因为不清楚RM是否已经忽略了事务，所以如果管理员进行了配置，我们试图针对该RM调用 忽略。我们返回 SAPHeuristicHazardExc印tion。在步骤616，如果TM到达本活动，则在事务处理期间一些事情严重出错可能是RM 内的故障、TM内的故障或它们之间的故障。也可能人类管理员已经干预过事务状态。这里 是可能的事情的列表(从DTP XA规范中引用的材料) “ [XAER_N0TA]资源管理器不知道指定的XID”。如果管理器决定手动提交或回滚 该未决事务，则可能是这种情况。
“ [XAER_INVAL]指定了无效的参量”。这指向RM或RM XA驱动器内的错误。
“ [XAER_PR0T0]在不适当的上下文中调用了例程”。这指向TM实现中的错误。
“ [XAER_ASYNC]在标志中设置了 TMASYNC，并且已经超过了未完成的异步操作的 最大数目，或者在资源管理器的Xa_SWitch_t结构的标志元素中没有设置TMUSEASYNC”。 Java 不支持异步事务的概念，因此这指向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 容器实现用于这种请求的唯一接口。目前存在三种不同风格的冊类型
泛型 Java 连接器资源(Generic Java Connector resources)-特别是出站资源 适配器(outbound resource adapter)连接器容器(aka连接器服务)负责这些RM的生 命周期。这包括配置数据的部署和管理。 数据源数据源容器(aka DBPool (数据库池)服务)负责系统数据源和所有 定制数据源的部署、配置和生命周期。数据源可以经由JDBCCJava 数据库连接)连接器 UI(用户接口)或通过部署data-source, xml资源文件来创建。还可以部署外露javax. sql. DataSource接口的Java连接器资源适配器-但是这种RM将不由DBPool服务管理，而 是由连接器服务管理。DBPool服务也负责数据源别名的管理，但是这些别名仅仅是对真实 数据源对象的引用。对于其它冊容器，也存在相同的别名概念。
JMS(Java 消息传递服务)队列/主题连接工厂(Queue/Topic CormectionFactory)。JMS容器(aka JMS连接器服务)负责这些资源的管理。JMS工厂的 配置数据从JMS连接器服务而不是从JMS提供者获得。从连接管理的观点来看，DBPool服务和JMS连接器服务表现得如同Java 连接器 容器一样。但是实际上，它们与应用服务器的Java 连接器容器严格分离，因为它们具有不 同的部署方法和不同的配置UI。从PTL处理器的观点来看，所有RM容器都是相似的。它们表现得如同XA资源工 厂一样。一旦XA资源工厂启动，它就将它自身登记到TM。因此，PTL处理器可以询问TM， 并且发现所需的XA资源工厂是否已经可用于服务XA资源创建请求。2. 5事务子系统的配合应用服务器的事务行为是若干事务子系统交互的结果。所有系统一起配合进行事 务处理和恢复。2.5. 1事务日志-高层视图事务日志可以位于数据库中或文件系统中。如果选择了文件系统，则强烈推 荐使用共享文件系统。即使文件系统不是共享的，事务恢复也将工作，但是没有即时 (on-the-fly)恢复能力。下面的部分将对此更详细地说明。每个集群节点具有一个事务管理器。该事务管理器在每次启动时创建新的事务日 志。如果日志在DBMS中，则所有日志条目将共享相同的表，但是它将有可能区分来自不同 的启动和不同的节点的条目。在文件系统的情况中，每个日志将是一个分开的文件。TM是该TL0G的拥有者并且 具有独占访问权。在图3中，该日志被称为TLog n(例如，320a)。2. 5. 2事务日志-补充条目如果TM正在运行而没有任何问题，则它将添加条目到TL0G。当然，典型的事务只 在非常短的时间内有效_之后它可以被删除，并且不需要保持它的存储器。根据实施例，这些删除操作不是立即执行，而是迟缓地执行。否则，对TL0G的写入 操作将加倍。如果事务结束，则将其添加到待删除牺牲者列表(Victim For DeletionList)。在 TM中可以存在若干这种列表每个TLG0 —个。
TM具有用于它在上次启动时创建的Tlog的待删除牺牲者列表。在它结束事务 时，它将事务添加到该列表。
PTL处理器可以对来自较早启动的TL0G进行操作。它维护用于这些TL0G中的 每一个TL0G的待删除牺牲者列表。 如果TM将有问题的事务提交到该PTL中，则PTL处理器也可以对当前有效的 TL0G的事务进行操作。因此，PTL处理器也可以向有效TL0G的牺牲者列表添加条目。待删除牺牲者列表是存储器内的结构。如果它达到一定的大小(例如，1000个条 目)，则该1000个条目将从TL0G中删除。这对基于DBMS和文件系统的TL0G不同地发生 如果TL0G是基于DBMS的，则记录将利用单个DELETE SQL语句删除。 如果TL0G是基于文件系统的，则将有一个或若干补充删除语句被添加到TL0G。 这些条目使用范围，例如“删除事务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中的条目，则它将该条目移除，并且将该事务放入待 删除牺牲者列表中。在该列表中的事务条目将被从TL0G中迟缓地删除(见上文)。工作 的成功完成也可以意味着事务经过了事务放弃超时，从而使得PTL处理器最终放弃该事务 (可能在一天失败的尝试之后)。变为孤立事务日志的拥有者PTL处理器从第一个条目到最后一个条目贯穿PTL连续循环。如果它再次从第一 个条目开始，则它检测“夺取事务日志标志”是否被设置。如果为是并且存在来自较早的启动的事务日志，则PTL处理器将试图变为对它们 负责。如果其成功并且获得TL0G，则其将读入该TL0G。记住，TM永远不会对除了它在上次 启动时创建的TL0G之外的任何TL0G感兴趣。如果TL0G是基于文件的，则读入日志可以以两阶段方式进行如已经提到的，可 能是存在补充较早的条目的针对TL0G中的事务的删除语句。因此，PTL处理器首先将TL0G 的所有条目读入存储器内的集结区域(in-memory staging area)。该区域将随着每个TLOG 记录增长，并且如果在TL0G中发现删除语句，则该区域再次收缩。如果PTL处理器完成了 对TL0G中的每个条目的读取，则它将只具有特定TL0G的最后条目，并且可能是更多的一些 在上次崩溃或关机时未决的单个事务。
然后，在第二阶段中，该集结区域中的所有条目变为已处理，并且它们中不能得到 立即解决的一些将被传送到PTL。如果日志是基于DBMS的，则不需要集结区域。DBMS日志被当作文件系统情况下的 集结区域那样对待。因此，将按照以下方式进行对集结区域或基于DBMS的TL0G的处理〇首先，PTL处理器(PP)将读取属于该TL0G的RM条目，并对它们调用恢复。〇如果该PP针对RM成功完成上述处理，则它将结果存储在存储器内的恢复结果 列表中。如果一个RM不可用，则该PP将用于该RM的NULL条目存储在恢复结果列表中。 NULL条目不是空列表。空列表意味着RM可用并且没有未决事务。〇在该初始过程的恢复调用之后，PP逐个处理集结区域中的条目。它重构在该事 务中涉及的所有冊的Id和条目的XID。该XID将与恢复结果列表中的所有XID比较。存在若干可能的结果*TL0G条目的XID不存在于任何恢复结果列表中。这意味着在任何RM中都不存在 未决事务。因此，事务可以简单地被忽略。它被添加到用于该TL0G的待删除牺牲者列表。*所涉及的RM之一的RM条目为空(null)，意味着该RM目前不可访问。因此，此 时不能决定特定事务在该当前不可用的冊中是否仍然未决。因此，其被添加到PTL。*XID在一些或全部所涉及的RM的恢复结果列表中。因此，PTL处理器将视图在这 些未决RM上解决该XID。如果成功，则事务完成，并且将该事务添加到待删除牺牲者列表。 如果不成功，则将其增加到PTL。〇如果在恢复结果列表中存在属于该TL0G但是不是该TL0G的一部分的XID，则回 滚这些RM中的分支(这是假定终止策略)。〇必须注意PTL处理器试图对当前不可用的RM调用恢复，即使在用于该RM的PTL 中不再存在条目也是如此。在该当前不可用的RM上仍然可能存在需要回滚的事务。PTL处理器必须跟踪TL0G是否完全结束并且可以被删除。因此，它针对每个TL0G 维护一个计数器，指示在PTL中有多少事务来自特定TL0G。如果该计数器达到零，则它从文 件系统或相关的DBMS表中删除相关联的TL0G。2. 5. 4 PTL 处理中的单例模式(Singleton Pattern)竞争 TL0GPTL处理器知道所有事务日志的位置，包括来自其它机器上的其它TM的事务日 志。在基于文件系统的日志的情况下，所述位置是简单的共享文件夹。如果PTL处理器控 制器中的“夺取事务日志标志”变为设置成真，则PTL处理器试图夺取所有可获得的事务日 志。在这样做时，它与位于其它节点的PTL处理器竞争。每个事务日志只有一个拥有者。这 实现了集群中的单例模式，这可常见于事务恢复的上下文中。在图3中，可以看到位于节点m上的PTL处理器夺取了由位于节点m+1上的TM产 生的TL0G。由PTL处理器负责来自另一节点的TM所产生的孤立TL0G没有任何坏处。因 此，实施例没有实现任何TM到PTL处理器的亲和逻辑(affinity logic)。因为当PTL处理器再次从PTL中的第一个条目开始时它只检查其“夺取事务日志” 标志的状态，所以在各集群节点之间至少存在一些负载均衡。概括来说，将“夺取事务日志标志”设置为真意味着启动恢复。但是谁负责设置该 标志？
21
*PP控制订阅集群节点丢失事件(Cluster Node Loss event)。在节点丢失时，该 标志被打开。这触发所有节点上的所有PTL处理器夺取孤立日志。这里的问题是，正常关 机也触发该事件_因此PP控制必须确保在将该标志设置为真之前在本地节点上不启动关 机。 在不想依赖于集群节点丢失事件的情况下，可以额外使用java. util. timer来 以预定义的时间可配置间隔将该标志设置为真。如上所述，PTL处理器竞争TL0G。那么如何保证单个TL0G永远不会有两个拥有者 呢？ 在基于文件系统的日志的情况下，同步是容易的PTL处理器调用相应 FileChannel上的tryLock方法。如果它得到锁定，则其它PTL处理器失败。如果节点崩 溃，则操作系统从文件移除锁定。 如果TL0G存在于DBMS中，则将存在TL0G表。对于每个逻辑TL0G，在该表中存 在一个记录。该记录包含拥有者和时间租用(time-lease)列。如果PP拥有TL0G，则它在 该表格中制作租用条目，指定其自身为拥有者，并且提供GMT时间，在该时间之前它拥有该 TL0G。如果它想要保留该TL0G，则它必须在租用时间结束前续租(renew)该条目。如果另 一 PP发现过期的TL0G拥有者条目，则它认为它的拥有者已死。这里的问题是，这种基于租 用的方式引入了等待时间。〇TM是TL0G的拥有者并且将其预留可配置的量10 (例如，10分钟)。〇该TM崩溃，激发节点丢失事件。〇另一节点上的PP扫描日志，并且看到该日志仍然被预留。因此，正常地它将不 会试图变为对该日志负责，尽管目前不再有任何拥有者关照该TL0G。这延迟了正在进行的 恢复。〇根据实施例的一个解决方案是，PP控制器知道崩溃的节点的Id(标识符)。因 此，如果崩溃的节点是TL0G的拥有者，则租用可能不再有效。该实施例的一个缺点是，崩溃 的节点可能已经再次启动，因此该TL0G实际上是全新的TL0G，或者是崩溃的节点的PP已经 在关照的TL0G。2. 5. 5节点启动为了说明事务组件的配合，这里是在集群启动期间执行的过程 首先，节点上的TM启动。它创建全新的事务日志并且独占地使用该事务日志。 之后，“夺取TL”标志将被设置为真。这将启动该节点上的PTL处理器。
PTL处理器打开它可以获得的第一孤立事务日志。它读入在该日志中使用的所 有RM。这是简单的，因为冊信息没有混合到正常的TL0G中，而是可作为额外的条目获得 (实际上，是作为分开的文件或分开的表)。-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处理器读入TL0G中的每个条目，与恢复结果比较并且填充(populate) PTL。
PTL处理器试图打开下一个TL0G，并且重复上面的后几个步骤。如可以看到的，每次节点启动都启动恢复过程。因为这个原因，即使TL0G位于非 共享文件系统的顶部，也将存在事务恢复。恢复将不是即时的，而是在崩溃节点的下一次启 动期间。当然，即时恢复是推荐的，因为其几乎是立即发生。恢复发生的越快，RM作出启发 式决定的可能性越小。2. 6事务超时2. 6. 1准备之前的XA事务超时存在不同的可能性来使用JTA定义事务超时。这些不同的可能性之一是在调用 当前javax. transaction. UserTransaction实例上开始(begin)之前调用同一实例上的 setTransactionTimeout(设置事务超时)方法。在分布式事务的情况下，该超时是事务必须在其间达到准备状态的时间跨度。如 果没有通过编程定义超时，则可以采用系统范围的默认参数(system wide default)。应当 可以额外定义优先于系统默认参数的资源管理器级别上的超时。因此，可以对异常慢的冊 的情况建模。TM 通过在调用 XAResource. start 之前调用 XAResource. setTransactionTimeoutO，来将该超时传播到所涉及的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处理器必须关照的某组事务。现在，处理器怎样才能决定冊中未决的事务是否属于它所负责的一组TL0G呢？答案很简单 首先，它检查格式ID是否为“SAP1”。如果是，则它知道它是创建事务的SAP NW(Netffeaver)JS(Javascript)TM。 然后，它比较编码到XID中的TL0G版本是否等于它当前负责的TL0G版本之一。 TL0G版本由以下部分组成系统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”可以用版本信息替代。分支限定符唯一地标识TL0G内的RM。扩展全局事务ID包括全局事务ID(Global Transaction ID)和分支迭代器 (Branch Iterator)。如果Java EE res-sharing-score被设置为不可共享，则分支迭代 器可能在少有的环境中使用。全局事务ID包括TL0G版本(TL0G version)、事务序列号(Transaction Sequence number)、事务出生时间(Transaction Birth Time)、事务放弃时间(Transaction Abandon Time)和TX名称标识符(TX Name Identifier)。TL0G版本标识事务日志实例。事务序列 号唯一地标识TL0G内的事务。事务出生时间是GMT格式的TM创建事务的日期和时间。事 务放弃时间是事务将被放弃的日期和时间。TX名称标识符是所使用的事务名称的唯一标识 符。基本上可以区分两种属性事务系统的正常工作所需的属性和驮载封装的 (piggy-packed)并给出关于特定事务的附加信息的属性。记住，由于假定终止策略，有时候 XID是在事务恢复期间TM具有的唯一信息。当TM决定回滚事务、因此不存在TL0G条目，但 RM返回XID作为恢复调用的结果时，就是这种情况。以下是对不同属性的目的的描述3. 3. 1事务序列号该号码唯一地标识TL0G内的事务。如果TL0G是基于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关联XAResourceL start (tx4711)； 现在，应用创建到相同RM的第二连接。调用与该连接XAResource〗相关联的XA 资源。正常地，TM将发出以下代码XAResource2. start (tx4711)；不幸的是，这将不能工作，因为XAResourcel和XAResource2指向相同的RM。该 RM将抱怨已经存在一个TM利用该全局事务ID启动了事务。该抱怨是有效的，因为RM不能 知道这两个连接背后的TM是同一个。RM必须假设存在两个访问它的TM，并且可能其中一 个将在稍后的时间点请求提交事务，而另一个将请求回滚事务。因此，它不能允许两个物理 连接与相同的XID关联。克服该问题的一种可能是对这些连接使用不同的全局事务ID。准确来说，该想法 提供1字节长分支迭代器。第一连接获得分支迭代器0，并且到相同RM的下一个连接获得 递增1的分支迭代器。以此类推。这将单个事务内到单个RM的连接数目限制为256，超过 256将抛出异常。对于RM而言，所述两个事务根本互不相关。因此如果资源共享被设置为不可共 享，则即使在单个冊内也会存在2PC语义(2PC semantics)。对于TM而言，它仍然是单个事务，并且如果TM决定要提交，则在TL0G中只有一个记录。3. 3. 6扩展全局事务ID全局事务ID是应用服务器(例如TM和PP)内的事务的表示。该ID还标识TL0G 中的事务。
外部RM看不到该全局事务ID，而是全局事务ID和分支迭代器的组合。两种属性 一起形成扩展全局事务ID。4.事务日志结构4.1事务日志的实体事务日志存储实现事务恢复所需的不同实体。这些实体包括TL0G实体、TL0G条 目实体、事务名称实体、RM实体和存储器内实体(In-MemoryEntities)。4. 1. 1TL0G 实体TL0G实体对每个逻辑事务日志具有一个实例(在DBMS情况中转换为一个记录)。 TL0G的拥有者能够通过更新该实例以及在拥有者属性中提供它的标识并在leasedUntill 属性中提供GMT时间(直到该GMT时间预留都有效)，来预留完整的日志。所述时间之后， 认为TL0G对任何人可用。拥有者是拥有者的角色(TM或PP)和集群节点ID的组合。在文件系统的情况下，该实体可能不是必需的。文件名称可以用作版本标识符，并 且通过OS控制锁定。4. 1. 2 TL0G 条目实体TM生成识别事务的全局事务ID。参与该事务的每个RM是分支，并且获得由TM分 配的分支Id。该分支Id对于TM的整个生命周期保持相同，这意味着从TM启动一直到关机 保持相同。如果事务使用之前TM不知道的新的RM，则TM将该RM添加到RM实体。分支Id 的生成可以简单地通过增加TM内部计数器来进行。分支IID存储在TL0G条目中的原因如下 考虑存在包括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没有被涉及。如果TL0G是基于文件的，则应当将校验和加到每个条目的结尾，例如，java. util. zip. CRC32。因此，很清楚我们具有有效的记录或死亡的TM的片段。4. 1. 3事务名称实体SAP TM允许另外指定人类可读的事务名称。在恢复服务稍后需要将问题报告给 管理员的情况下这是有用的。代替报告“Xid 4711具有启发式结果”，消息可以是“事务 “OrderBooking”具有启发式结果”。事务名称永远不应当特定于如“order#12345”的事务 实例，它更像是事务分类符。事务名称的另一优点是监控可以变得更有意义。可以根据事务名称向下钻取 (drill down)事务吞吐量和故障。TM在它对任何RM进行第一次准备调用前写入事务名称实体。在TL0G自身中，只 存储较短的transactionNameld(事务名称ID)，其是全局事务ID的一部分。如果应用没有 使用事务名称，则将不写入记录。利用事务名称存在一个风险如果应用使用事务实例特定的名称，则结果是TM除了要更新TL0G之外，还要对每个事务执行一次到该条目的写操作。这将使写入操作的数量 加倍。同样，事务名称表将无限地增长。因此，根据实施例，可以存在对事务名称的最大数目的可配置的限制，例如1000。 该数目后，新的事务名称将被忽略。或者，可以实现用于内部事务名称高速缓存的LRU(最 近最少使用)策略。因为允许高数量的事务名称没有明显好处，所以这有可能矫枉过正。4. 1. 4 RM 实体 如已经提到的，TM创建在其生命周期期间该TM所使用的所有RM的持久实体。该信 息必须足以用于在恢复时重建XA资源管理器。这暗示着要存储XAResourceFactorylcKXA 资源工厂ID)，指向能够创建该类型的XAReS0Urce(XA资源)的资源工厂。该工厂也具有名 称、属性和执行重建任务的凭证。如果TL0G是基于文件系统的，则RM实体变为它自己的文 件。因为它存储凭证，所以它将被加密。在TL0G实体被消化(digest)前，RM实体将被PTL处理器读入。将针对RM实体 内的所有冊进行恢复调用，此后，TL0G条目将被处理以填充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将以以下方式对TL0G条目表执行单个删除操作DELETE FROM TL0G_ENTRIES WHERE XID IN(Xidl, Xid2, . . .，XidlOO)PTL处理器将以类似方式进行条目的删除。如果便随着填充PTL来进行该操作，则 它知道在TL0G中的但是不再有效的所有Xid。将发出与上面示出的类似的SQL删除操作。如果TM遇到正常关机过程并且不再有有效事务，则它可以自由地额外删除TL0G 表中代表整个事务日志的记录。如果对于某个事务日志恢复服务不再具有未决事务，则其通过删除TL0G表中代 表该事务日志的记录来附加地删除整个事务日志。
27
4. 2. 2基于文件系统的事务日志如果TL0G是基于文件系统的，则必须注意新文件中的溢出。由于TM知道所有有 效的和未决的事务，所以如果文件达到预定义的可配置的实体数量(例如，1000)，则发生 下面的溢出过程 新的事务日志文件被创建。 新的RM日志文件被创建。 所有有效的和未决的事务被复制到新的日志文件。 由这些有效的和未决的事务使用的所有RM被复制到新的RM日志。 指向旧文件的所有内部数据结构将被更新，以使它们指向新文件。 删除旧文件(TL0G和RM日志)。恢复服务不删除任何单独的实体。但是其检查其是否处理了属于某个事务日志的 最后的未决条目。如果是，则其删除该最后的未决实体所属于的TL0G和RM日志。因为存 在典型为大约一天的事务放弃超时，所以在最后的条目被添加之后，整个事务日志不能存 活超过一天。5.插人的事务管理器(Interposed Transaction Manager)在大多数使用情景中，应用服务器在它的事务的完全控制之下。对此的一个显著 例外是由Java连接器架构引起的，Java连接器架构从发布版本1. 5开始。在该规范中，定 义资源适配器可以将引入的事务(imported transaction)传播到应用服务器，以使得应用 服务器和随后的参与者可以进行作为该引入事务的一部分的工作。该规约允许资源适配器流入(flow-in)事务完成和由企业信息系统(EIS)发起的 崩溃恢复调用。这样概括，应用服务器用作对外部事务管理器的普通RM。为了达到这个目的，应 用服务器容纳插入的TM 它向外部TM提供像RM那样的接口，并且像普通TM那样协调内部冊。进入的事务的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，HEURC0M， HEURMIX, HEURHAZ)。在已经经过了事务放弃时间之后，插入的TM将试图启发式地回滚事务。该操作的 结果将被存储在事务日志中，因此可以在下一次外部TM试图继续该事务或对该插入的TM 调用恢复时报告该结果。插入的TM将保留关于启发式完成的事务的条目，直到外部RM调 用关于它的忽略为止。5. 3集群内的插入的事务管理器如同许多Java EE规范一样，Java 连接器架构不处理成集群环境中的故障转移 (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类型的处理相比，两阶段提交事务处理由于其物理1/0而显得非常繁重。 这主要是由于在单个事务中需要若干盘力(disc force)的事实。作为示例，考虑涉及两个 RDBM的事务，这两个RDBM全部写入相同的盘 在准备时，两个RM都具有盘力-每个RM 1个-总共2个。 如果TM决定提交，则其写入TL0G-另一盘力。 两个RM都提交-另外2个盘力。 稍后，TL0G条目被清除-但是这不需要再一次的盘力。因此结果是总共5个盘力，而不是使用本地事务的情况下的单个盘力。盘力所需 要的时间量可以预期为在5到50毫秒之间，这取决于可用的盘。如果事务有效载荷小，则 盘同步可能变为事务处理中的主要部分，因此盘同步需要尽快。实施例通过将对TL0G的更新分组到一起并且将其作为对文件系统或DBMS的单个 操作的一部分来执行，而增加吞吐量。实际上，这意味着访问TM的一组应用线程被延迟，直 到完成同步，因为它们全部在单个同步操作中被分组到一起。
低于临界吞吐量，将对TL0G的更新分组到一起没有意义。对日志的每个更新通 过应用线程本身来执行。因此，每个同步操作对TL0G的更新的数量为1。 高于临界吞吐量，I/O变为瓶颈。想要添加到TL0G的应用线程多于盘或DBMS能 够处理的应用线程。这引入了对系统能够实现的最大吞吐量的严重限制。为了克服这一问题，将不同应用线程的更新分组到一起，并且将其作为针对TL0G 的单个同步操作来执行。如果TM的事务吞吐量增加，则越来越多的对TL0G的更新被分组 到一起。根据实施例，TM实现随后支持两种模式 低吞吐量模式TL0G在应用线程内更新。
TL0G批处理模式在单独的线程中进行TL0G更新。这里的一个挑战是决定何时切换到TL0G批处理模式是有利的，换句话说，如何定 义临界吞吐量数量。该数量取决于硬件。实施例实现了自适应机制，其通过尝试以下步骤 来找出该数量 在TL0G批处理模式中，每个应用线程将它的TL0G更新附加到缓冲器中。 单独的线程获取缓冲器的内容并将其写入TL0G。如果该线程完成写入，则它将 发现缓冲器已经被填入了许多添加到该缓冲器的应用线程。该线程将再次获取缓冲器并释 放等待的应用线程。以此类推。 如果该线程返回并且看到在缓冲器中没有或只有一个条目在等待，则该线程知 道它不被真正需要。不存在要分组的请求。它会将EmptyCycle计数器增加1。 如果线程发现缓冲器被填入了多于1个条目，则其将NonEmptyCycle增加1，并 且将EmptyCycle计数器设置回0。 如果EmptyCycle计数器超过预定义的空周期的最大数目(例如，100)，则线程切 换到低吞吐量模式并且去激活它自己。这是TL0G批处理子系统的退出准则。批处理子系 统不立即去激活它自己的原因在于要实现滞后行为。如果事务系统在临界吞吐量附近，则 它将不会在LOG批处理和低吞吐量模式之间持续地振荡，而是只有当存在较长时间跨度的 低事务需求时的振荡。在现在清楚了何时TM会将TL0G批处理模式关闭后，问题是何时将它打开。为此， 可以使用NonEmptyCycle计数器如果NonEmptyCycle计数器小，则意味着TL0G批处理子 系统实际上没有很多事情要做。换句话说，将其从最开始就打开是没有意义的。另一方面，TM知道当前的事务吞吐量。这通过对总的事务量计数并将它们除以它 们所花费的时间来实现(例如，全部100个事务或全部10秒，计算吞吐量)。因此，如果NonEmptyCycle为低，则可以得出结论在当前事务速率下将批处理模 式打开是没有意义的。这定义了对于临界吞吐量数量的新的猜测。如果当前事务速率高于 临界吞吐量数量，则TM再次将TL0G批处理模式打开。在一些迭代之后，临界吞吐量值将达 到与当前硬件设备相称的速率。图8是用于实现本发明实施例的示例计算机系统和网络1400的方框图。计算机系 统1410包括总线1405或用于传送信息的其它通信机制、以及与总线1405耦合的用于处理 信息的处理器1401。计算机系统1410还包括耦合到总线1405的用于存储由处理器1401 执行的信息和指令的存储器1402，所述信息和指令包括用于执行上述技术的信息和指令。该存储器还可以用于存储在执行由处理器1401执行的指令期间的临时变量或其它中间信 息。该存储器的可能实现可以是，但是不限于，随机存取存储器(RAM)、只读存储器(ROM)或 它们两者。还提供存储设备1403用于存储信息和指令。存储设备的通常形式包括例如硬 盘驱动器、磁盘、光盘、⑶-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)。上面的描述说明了本发明的各种实施例以及本发明的各方面可以如何实现的示 例。上面的示例和实施例不应当被认为是仅有的实施例，而是呈现来说明由权利要求定义 的本发明的灵活性和优点的。基于上面的公开内容和权利要求，其它安排、实施例、实现和 等效方式对本领域技术人员将是明显的，并且可以被使用而不偏离权利要求定义的本发明 的范围。
权利要求
一种用于分布式计算环境中的事务恢复的系统，包括事务日志服务器，其存储共享事务日志；多个应用服务器，其实现分布式事务应用，并且在使用分布式事务应用执行事务时，访问所述共享事务日志；以及多个资源服务器，其存储数据，并根据事务与所述多个应用服务器操作以访问数据，其中所述多个应用服务器、多个资源服务器和事务日志服务器通过经由网络连接的多个硬件设备实现，以及其中如果所述多个应用服务器中的应用服务器变为故障应用服务器，则有效应用服务器承担之前由所述故障应用服务器访问的共享事务日志的部分的责任。
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所述的计算机程序，其中所述多个应用服务器中的应用服务器包括事务管理器，其对所述共享事务日志执行分组更新。
全文摘要
在一个实施例中，本发明包括一种用于分布式计算环境中的事务恢复的系统。该系统包括事务日志服务器、应用服务器和资源服务器。事务日志服务器存储共享事务日志。应用服务器实现分布式事务应用，并且在使用分布式事务应用执行事务时，访问共享事务日志。资源服务器存储数据，并根据事务与多个应用服务器操作以访问数据。如果所述多个应用服务器之一出现故障，则另一应用服务器承担之前由故障应用服务器访问的共享事务日志的部分的责任。
文档编号H04L1/22GK101853186SQ20091026602
公开日2010年10月6日 申请日期2009年12月31日 优先权日2008年12月31日
发明者尼古莱·D·坦科夫, 彼得·H·佩谢夫, 托马斯·H·沃尔特, 拉尔夫·库希 申请人:Sap股份公司