CN1554056A

CN1554056A - 具有同步回退处理特征的事务处理的系统和方法

Info

Publication number: CN1554056A
Application number: CNA028177193A
Authority: CN
Inventors: ��»��P��Ѷ��; 爱德华·P·费尔特; 普里西拉·冯; J��Ī��; 亚历山大·J·索莫吉; ķ��˹��᷶ɣ; 斯里拉姆·斯里尼范桑
Original assignee: BEA Systems Inc
Current assignee: Oracle International Corp
Priority date: 2001-07-17
Filing date: 2002-07-16
Publication date: 2004-12-08
Anticipated expiration: 2022-07-16
Also published as: EP1417558B1; AU2002322495B2; WO2003009093A2; JP2004536402A; EP1417558A4; US20030036919A1; US8001546B2; US20080066068A1; CN1554056B; EP1417558A2; ATE550714T1; JP4550411B2; US7337441B2; WO2003009093A3

Abstract

本发明提供一种在事务或者消息完成之前允许事务回退处理被同步或者实行的机制。在事务活动阶段期间，可以在任何一个服务器上注册参与事务的附加同步对象(704)。调用提交(commit)功能之后，在事务预准备阶段处理期间调用每个同步对象。一个同步对象可以注册另一个同步对象，调用未预先包含在事务中的一个服务器(706)，或者把一个新XA资源并入事务中。本发明的效果是提供一种请求传送的循环方案，以允许在提交之前把附加资源加入到环中(710)。

Description

具有同步回退处理特征的事务处理的系统和方法

技术领域

本发明一般涉及应用程序和事务服务器，特别是涉及一种允许回退(callback)处理与事务或者消息的完成相同步的系统。

优先权要求

本申请要求以下美国申请的优先权：于2002年7月15日提交的申请号为＿＿的美国实用新型申请“具有同步回退处理特征的事务处理的系统和方法”，以及于2001年7月17日提交的申请号为60/306105的美国临时申请“具有同步回退处理特征的事务处理的系统”，以及于2001年7月30日提交的申请号为60/308693的“具有同步回退处理特征的事务处理的系统”，上述申请在此引用，以资参考。

交叉参考

本申请涉及共同待审的实用新型申请“具有事务特性特征的事务处理的系统(SYSTEM FOR TRANSACTION PROCESSING WITH PROPERTYFEATURE)”(申请号＿＿，发明人：Edward P.Felt，Priscilla Fung，Alex Somogyi，Sriram Srinivasan；2002年7月15日提交)，和“具有委托提交特征的事务处理的系统(SYSTEM FOR TRANSACTION PROCESSING WITHDELEGATED COMMIT FEATURE”(申请号＿＿，发明人：Edward P. Felt，Priscilla Fung，Alex Somogyi，Sriram Srinivasan，2002年7月15日提交)；在此对这两件申请整体引用，以资参考。

背景技术

Java2平台企业版(J2EE)规范定义了开发多层企业应用程序的一个当前标准。J2EE为企业应用程序的设计、开发、装配和部署提供了一种基于组件的方法，既降低了成本又能够更快速设计和实施。J2EE向开发者提供了多层分布式应用程序模型、再利用组件的能力、统一标准的安全模型以及灵活的事务控制。它们不仅能够比以往更快地向市场提交创新的顾客方案，而且还不把所得到的平台独立的J2EE基于组件的方案捆绑到任何一个卖方的产品和应用程序接口上。

J2EE规范定义了以下各种组件：应用程序客户组件；企业JavaBeans(EJB)；servlet(小服务程序)和Java服务器页(JSP)(还称之为Web组件)；小程序(applet)。多层分布式应用程序模型是指根据功能将应用程序划分成多个组件，并且不同的应用程序组件可以构成相同或者不同服务器上的J2EE应用程序。实际安装应用程序组件依赖于应用程序组件属于多层J2EE环境中的哪个层。这些层在图1中示出。如图所示，应用程序服务器层4用来开发EJB容器和/或表现容器如servlet、JSP和html页14。这些容器又用作客户层2与尾端层6之间的接口，其中在客户层2中部署客户8和客户应用程序，而尾端层6用来担当企业或传统应用程序如企业资源规划(ERP)系统的宿主。

客户层-这些可以是浏览器、基于Java的程序，或者运行于客户层内并位于公司防火墙内侧和外侧的其它Web使能编程环境。

应用程序服务器层-该层通常担当支持客户请求的表现逻辑和商务逻辑组合的宿主。表现逻辑经由显示HTML页的JSP页和servlet来支持，而商务逻辑经由远程方法调用(RMI)对象和EJB12来支持。EJB依赖事务的容器环境、寿命周期和状态管理、资源组合、安全性等，它们共同构成运行bean的运行时间环境。

尾端层-这通常是现存应用程序和数据存储的组合。它还被称之为企业信息系统(EIS)层，因为它可以包含如企业资源规划(ERP)、主机事务处理、数据库系统和其它老式信息系统那样的系统。

由于J2EE应用程序的各组件分别运行，并且常常是不同装置，因此需要有一种查找和引用其它码和资源的客户及应用程序服务器层码的方式。客户和应用程序码例如可以使用Java命名和目录接口(JNDI)16查找用户定义的对象如企业bean和环境项目如Java数据库连接器(JDBC)数据源对象位置，而环境项目又用来查找尾端层中的资源以及消息连接。

在Web和企业bean组件上的部署时间，可以配置应用程序行为如安全性和事务管理。该部署时间特征将应用程序逻辑与可能随组装变化的配置设置相分离。J2EE安全性模型使开发商配置一个Web或者企业bean组件，以便系统资源只能由授权用户访问。例如，Web组件可以被配置成提示输入用户姓名和口令。企业bean组件可以被配置成仅仅使特定组中的人可以调用某种方法。作为选择，servlet组件可以被配置成具有某些可以访问每个人的方法，以及具有一些在一个组织中只有某些被特许的人才可访问的方法。可以为所有方法都能用于每个人或者所有方法仅能用于一些选择的人的另一环境配置相同的servlet组件。

某些应用程序服务器，比如产自BEA系统公司(San Jose，california)的WebLogic服务器，使用了一个访问控制目录(ACL)机构，该机构考虑了运行在服务器上的组件使用的细颗粒控制(fine-grained control)。通过使用ACL，开发商可以以Java方法等级定义哪个用户或者哪些用户组可以执行什么或者不可以执行什么。该ACL机构覆盖了除EJB外的运行在应用程序服务器上的任何事，该EJB具有EJB规范所定义的它们自己的访问控制机构。安全区域允许管理器把来自现有的授权或确认系统的信息输入到ACL中。

Java Servlet

servlet是一个扩展Web服务器的功能的程序。servlet接收来自客户的一个请求，动态地生成答复(也许查询数据库以履行该请求)，然后向客户发送包含HTML或XML文件的答复。Servlet类似于CGI但通常更适合于写，因为servlet使用Java类别和流。它们运行更快，因为Servlet被编译成Java字节码，并且servlet事件在运行时间被保存在存储器中，每个客户请求运行在单独线程中。servelt使它容易地以动态方式产生到达HTTP答复流的数据。客户请求在新连接结束后来执行，所以流控制不会自然干预请求。为此，该对话管理保持请求之间的特定客户的状态。在某些应用程序服务器中，诸多sevlet利用HTTP对话对象保存它们的方法请求之间的状态。为了克服故障(failover)目的，可以在群集环境(clustered environment)中复制该对象。

Java服务器页面

JSP页面是一个开发servlet的基于文本的表达中心途径(way)。JSP页面提供了servlet的所有利益，当与JavaBeans类组合时，它提供了一种容易的方式来保持内容并显示逻辑分离。JSP页面和servlet比公共网关接口(CGI)更理想，因为它们是独立平台，并且使用少量开销。JSP页面可以和JavaBeans一起用来定义Web模板，该模板建立具有相似外貌和感觉的由多个页面构成的Web站。JavaBeans类执行数据再现，所以模板没有Java码。这意味着它们可以由HTML编辑器来保持。使用JSP页面的简单的基于Web的应用程序可以用来把内容捆绑到使用替代JavaBeans类的自定义标记或scriptlet的应用程序逻辑上。自定义标记被装入到标记库中，而该标记库被输送到一个JSP页面中。Scriptlet是直接装入JSP页面的小Java码段。

数据库访问业务(JDBC)

JDBC充当一个抵达关系数据库的桥，并且效法ODBC(开放式数据库连接)规范。通过使用驱动器断开数据库与程序码的连接。JDBC的某些实施提供了对高级数据型的支持，并且还支持滚动结果集和批更新的功能。

Java消息传递业务(JMS)

JMS是用来支持Java程序间消息交换的J2EE机制。Java就是这样支持异步通信的，其中发送方和接收方不需要彼此知道，因而可以独立操作。JMS支持以下两种消息传递模型：

点对点-基于消息队列。在该模型中，消息制作商把消息发送到队列上。消息顾客可以把该消息附加到队列上以便收听消息。当消息到达队列时，用户可以将消息从队列中取出，并对此答复。可以只向一个队列发送消息，并且将只由一个顾客使用该消息。顾客可以任意过滤消息，以选出它们想要的正确消息类型。

公布和预定-允许消息制作商发送消息到一个专题，该专题的所有注册用户检索这些消息。在此情况下，许多顾客可收到相同的消息。

Java接口定义语言(IDL)

CORBA对象使用IDL指定一个契约，即它们如何与其它对象进行相互作用。有了Java IDL，就可以在Java领域和CORBA领域之间定义契约。自SUN的JDK1.2开始，都包括一个ORB，它允许Java应用程序经由互联网InterORB(IIOP)协议调用远程CORBA对象。

企业JavaBran(EJB)

EJB组件为封装商务逻辑而设计，所以开发商不必关心典型作业如数据访问、事务支持、安全、高速缓存和并行操作的代码编程。在EJB规范中，这些作业是EJB容器的职责。企业bran由接口和类别组成。客户经由企业bean的本地和远程接口访问企业bean方法。本地接口提供创建、消除和定位企业bean的方法，远程接口提供商务方法。在部署时，容器创建源自这些接口的类别，然后利用该类别向客户提供访问，使客户寻找创建、消除、定位和调用的企业bean的商务方法。企业bean类提供商务方法、创建方法以及探测器(finder)方法的实施；如果bean管理它自己的持续性，则提供其寿命周期方法的实施。

有两种类型的企业bean：实体bean和会话bean。会话bean表达与客户的瞬态对话，并且可以执行数据库读和写。会话bean可以调用JDBC调用本身，或者可以使用实体bean进行调用，在此情况下，会话bean是实体bean的一个客户。会话bean的字段包含对话状态并且是瞬态的。如果服务器或者客户崩溃，则会话bean完结。

实体bean表达数据库中的数据以及作用于该数据的方法。在用于一个雇员信息表的关系数据库上下文中，可能存在用于该表每一行的一个bean。实体bean是事务性的和长寿的。只要数据保持在数据库中，实体bean就存在。该模型可以容易地用于关系数据库，并且不限于对象数据库。

会话bean可以是有状态的或者无状态的。有状态会话bean包含代表客户的对话状态。对话状态是会话bean瞬态字段值加之可以从会话bean字段得到的所有对象。有状态bean不表达持久数据存储中的数据，但是它们可以访问和更新代表客户的数据。无状态会话bean没有任何用于特定客户的状态信息。它们通常提供不保持任何特定状态的服务器侧行为。无状态会话bean需要少量的系统资源。提供属类业务或者表达已存数据的共享意图的商务对象是一个无状态会话bean的良好候选者。

使用容器管理持久性访问关系数据库的企业bean不需要开发商使用任何用于数据库访问的JDBC2.0API，因为这由容器处置。然而，如果bean管理持久性被用来访问一个不同于关系数据库的企业信息系统，或者如果存在访问一个不同于关系数据库的企业信息系统之需要，则必须提供适当的代码。

在企业bean使用bean管理持久性访问数据库的情况下，具有JDBC2.0API码的bean的寿命周期方法必须被实施为处理数据装载和存储数据，以及保持运行时间与持久数据库存储之间的一致性。尽管Web层使用HTTP或者HTTPS在层之间传递数据，但是EJB层使用了RMI-IIOP。RMI-IIOP是满标度分布式计算协议，该协议向任何客户或Web层提供访问企业bean的程序，以直接访问EJB层中的业务。这些业务包括引用企业bean的JNDI、发送和接收异步消息的Java消息传递业务(JMS)和用于关系数据库访问的JDBC。

事务管理

任何应用程序服务器如WebLogic服务器系统的最基本特征之一是事务管理。事务是保证数据库事务被精确完成并使其呈现高性能事务的所有“ACID”特性的手段，包括：

原子性-事务对数据库作出的所有变化都是永久性的；否则，返回所有变化。

一致性-一个成功的事务把数据库从以前的活动状态转换到新的活动状态。

隔离-在事务完成其工作之前，对数据库作出的变化是其它操作看不到的。

持久性-事务对数据库作出的变化在系统或媒介以后出现故障时，仍然有效(保存)。

J2EE事务模型使应用程序开发商在部署时间，指定包括单一事务的多个方法间的关系，所以把一个事务中的所有方法视为一个单一单元。这是理想的，因为事务是必须全部完成的一系列步骤，或者，如果这些步骤没有全部完成，则倒退这些步骤。例如，开发商可以有企业bean中的一系列方法，即通过将资金记入借方的第一帐户，然后存入第二帐户，把资金从一个银行帐户转移到另一个帐户。在该实例中，它们希望把实体转移操作视为一个单位，所以，如果在记入借方之后和存入之前存在一个故障，则回退记入借方操作。

在安装期间，事务特性被指定到应用程序组件上，允许开发商经过应用程序组件把诸多方法集合成事务。这样，可以在J2EE应用程序内改变应用程序组件，并且重新分配事务特性而不改变代码。Java事务业务(JTS)和Java事务APJ(JTP)在J2EE中构成事务支持的基础，特别是构成对EJB和JDBC2.0的事务支持的基础。JTS规范是用于事务管理的低级应用程序接口(API)，其中该事务管理把Java映射到对象管理组(PMG)对象事务业务。JTA规范由Sun Microsystems与事务处理和数据库系统业界的主要工业伙伴共同开发，该规范指定了事务管理器、资源管理器、应用程序服务器与事务应用程序之间的标准Java接口。具体而言，JTA是一个包括以下两个部分的高级API：

事务接口-它能够使分布式组件执行的工作受全局事务制约，并且是标记或者标识构成事务的操作组的一个通道。

XA资源接口-一个基于X/Open接口或者XA接口的接口，该接口能够启动分布式事务的处理。这些接口都包含对一个以上资源(如一个数据库或者队列之内或者之间)上的事务的协调。

开发商通常不需要关心用JTA编程显性事务，因为该工作是通过由容器处理的JDBC和EJB APL执行的，并且通过应用程序部署说明符来配置。开发商可以把精力集中到事务的设计上，而不是集中到事务的实现上。

Weblogic服务器支持企业应用程序的分布式事务以及两阶段提交协议。分布式事务是以协调方式更新多资源管理器(比如多个数据库)的事务。相反，一个本地事务更新单一资源管理器。两阶段提交协议是在两个或多个资源管理器上协调单一事务的方法。它是这样保证数据完整性的，通过确保事务更新被提交到所有参与的数据库中，或者从所有数据库完全回退事务更新，使其还原到事务开始之前的状态。换言之，更新所有参与的数据库，或者不更新它们。分布式事务包括以下参与者：

事务始发器-启动事务。事务始发器可以是一个用户应用程序、一个企业JavaBean或者JMS客户。

事务管理器-管理代表应用程序的事务。事务管理器通过与正在参与这些事务的资源管理器进行通信，来协调来自应用程序的开始和完成事务的命令。当资源管理器在事务处理期间发生故障时，事务管理器协助资源管理器决定提交还是回退待决事务。

可恢复的资源-提供数据的持久性存储。该资源通常是一个数据库。

资源管理器-提供对信息和处理的集合的访问。

事务察觉JDBC驱动器(transaction-aware JDBC driver)是公共资源管理器。资源管理器提供事务能力和动作的持久性：它们是分布式事务内访问和控制的实体。资源管理器与特定资源之间的通信被称为一个事务分支(branch)。

两阶段提交协议的第一阶段被称之为准备阶段。所需的更新必须被记录到事务日志文件中，资源必须经过一个资源管理器指示它准备进行改变。资源可以投票提交更新也可以返回到先前状态。第二阶段中出现的事情取决于资源如何投票。如果所有资源都投票提交，则更新参与事务的所有资源。如果一个或多个资源投票为返回，则将参与事务的所有资源返回到它们的先前状态。

商务事务的支持

这些事务是以下说明的实例情况中的适宜事务(虽然这些情况仅仅是例证而不是穷举)。

作为第一实例，客户应用程序需要调用几个对象，这些对象可以包括对一个或多个数据库的写操作。如果任何一个调用不成功，则必须返回写入(写入存储器，更典型的是写入数据库)的任何状态。例如，考虑一个旅游代理应用程序。客户程序需要安排到远地点的旅程；例如，从法国的斯特拉斯堡到澳大利亚的阿利斯斯普林斯。这样一个旅程不可避免需要多个单个飞行预约。客户应用程序通过按顺序预约旅程的每个单个段来工作；例如，斯特拉斯堡到巴黎，巴黎到纽约，纽约到洛杉矶。然而，如果任何一个单独飞行预约不能做到，则客户应用程序需要一个通道取消接近那一点的所有飞行预约。客户应用程序需要与服务器应用程序管理的对象交谈，并且需要对特定对象实例作出多个调用。交谈也许具有以下的一个或多个特征：

在每个连续调用期间或者之后，将数据高速缓存到存储器中或者写入数据库中；在调用结束时，将数据写入数据库中；客户应用程序需要对象在一个存储器内保持每个调用之间的上下文；也就是，每个连续调用使用交谈期间保持在存储器中的数据；在交谈结束时，客户应用程序需要有能力消除交谈期间或者交谈结束时可能出现的所有数据库写操作。

作为一个替代实例，考虑一个基于互联网的联机购物车应用程序。客户应用程序的用户浏览联机目录并作出多个购物选择。当用户选择它们想要购买的物品时，用户进行检验并输入其信用卡信息以进行购买。如果信用卡检验失败，购物应用程序需要一个机制来消除购物车中的所有待购买选择，或者回退交谈期间作出的任何购买事务。在对对象的单个客户调用的范围内，对象对数据库中的数据执行多个编辑。如果这些编辑之一失败，则对象需要一个机制回退所有编辑(在此情况下，各数据库编辑不一定进行EJB或RMI调用。一个客户如一个小程序使用JNDI可以获得对事务和事务管理器对象的引用，并开始一个事务。)

作为另一个实例，考虑一个银行业应用程序。客户调用对出纳员对象的转帐操作。转帐操作需要出纳员对象对银行数据库作出以下调用：调用关于一个帐户的借记方法；调用关于另一个帐户的借记方法。如果银行数据库的借记调用失败，则银行业应用程序需要一个机制来返回先前的借记调用。

上述传统的事务管理方法的问题是，在处理事务返回的方式中效率低下。每个提交服务器必须直接接触每个参与的服务器，然后再通知客户。此外，传统方法缺少灵活性，例如，在调用提交功能之后，没有允许新服务器或资源参与事务的机制。这限制了传统方法的可伸缩性和适用性，并阻碍了今日商务所需的日益增加的复杂应用程序的开发。

发明内容

本发明提供了一种供应用程序服务器或者事务处理系统使用的机制，允许在事务完成之前同步(或生效)回退处理。在事务的寿命周期，存在几种状态转换，包括活动、切换、预准备、准备、记录与提交状态之间的转换。根据本发明的一个实施例，在活动阶段期间可以在任何服务器上注册同步对象。在提交()功能被调用之后，在准备处理阶段调用每个同步对象。一个同步对象可以注册另一个对象，或者可允许一个同步对象调用一个以前未包含于事务中的服务器。同步对象还可以包含事务中的新XA资源。在本文中，术语同步和同步对象是指需要事务管理器在调用提交之后，调用一个完成前同步(Synchronization.beforeCompletion)方法的JTA规范所指定的编程接口。应用程序码在事务的活动阶段注册这些回退。

循环控制流在服务器的一个环中流动，并在完成所有同步回退时结束于提交服务器。如果以后添加新同步对象或者服务器，则可以把它们插入环中。所有同步回退在准备任何资源之前完成，以处理同步回退需要访问资源的这些事件。与提交服务器应当直接接触每个参与的服务器的传统方法相比，该循环控制流处理减少了消息的数量。动态增加服务器和资源、沿循环控制流传送该服务器目录的能力，极大地增加了事务处理系统、应用程序服务器和建于该服务器顶部的应用程序的灵活性。在实施例中，本发明包括一种将事务回退与一个事务完成相同步的事务处理系统，该系统包括：可关联一个事务的多个同步对象和资源；一个事务协调器，为一个特定事务注册至少一个或多个事务子协调器的组，和注册参与特定事务的同步对象回退和资源的选择；其中，该事务子协调器组可以在提交事务之前修改，以反映参与特定事务的同步对象回退和资源的选择的变化。

附图说明

图1显示了J2EE体系结构的图示；

图2显示了本发明实施例的同步回退特征的图示；

图3显示了供本发明使用的典型客户服务器系统的图示；

图4显示了本发明实施例的各种事务状态的图示；

图5显示了本发明实施例的事务同步回退系统的第一图示；

图6显示了本发明实施例的事务同步回退处理的流程图；

图7显示了供本发明实施例的一个开始事务寿命周期的图示；

图8显示了本发明实施例的事务传播寿命周期的图示；

图9显示了本发明实施例的提交寿命周期的图示；

图10显示了本发明实施例的预准备阶段寿命周期的图示；

图11显示了本发明实施例的准备阶段寿命周期的图示；

图12显示了本发明实施例的提交阶段寿命周期的图示；

图13显示了本发明实施例的返回寿命周期的图示；

图14显示了本发明实施例的恢复寿命周期的图示；

图15图示说明了本发明实施例的事务如何在EJB应用程序中工作；以及

图16图示说明了本发明实施例的事务如何在RMI应用程序中工作。

具体实施方式

一般来说，本发明提供了供事务或应用程序服务器使用的一种机制，它允许在事务完成之前同步回退处理。在该时期，可以在事务活动阶段把同步对象注册在任何一个服务器上。当调用提交功能时，又在准备阶段调用每个同步对象。这样做的优点是，可以在提交周期之前将同步对象添加到链上。一个同步对象可以注册另一个对象或者可允许一个同步对象调用以前未包含在事务中的服务器。

循环控制在服务器之间的一个环中流动，并在所有同步回退完成时结束于一个提交服务器上。如果以后增加新同步对象或者服务器，则将它们插入环中。在准备任何一个资源之前完成所有同步回退，以处理同步回退需要访问资源的事件。与提交服务器应当直接接触每个参与服务器的传统方法相比，循环控制流减少了消息的数量。动态增加服务器和资源、沿循环控制流传送该服务器目录的能力，极大地增加了事务处理系统、应用程序服务器和建于该服务器顶部的应用程序的灵活性。

图2图示说明了本发明的一个实施例，显示了在提交和回退阶段之前，附加服务器和同步对象如何被包含在同步回退环中。如图2所示，包括客户应用程序104的客户102启动或者开始包含一个服务器106或者这些服务器上的资源的事务。通常，客户应用程序104将指定一个特定事务上下文112，该上下文告知诸多服务器其中哪些服务器和哪些服务器资源对象或资源应当被包含在特定事务中。在这里，术语“同步对象”是指允许服务器参与事务的服务器对象。在包括基于Java系统的面向对象的系统中有规则地使用同步对象，以保持瞬态状态数据。在事务完成之间，同步对象将数据往返于向相同事务注册的一个或多个资源对象。例如，如图2所示，事务上下文112可以指定服务器1108和服务器A110将参与的事务，该事务包含一个或多个位于服务器A上的对象或资源116。需要注意的是，在一个实施例中，服务器106的任何一个可以选作开始处理链的初始服务器1。当预准备阶段期间，在提交时期之前将诸多服务器加入到环中。在提交事务之前的任何点上，客户应用程序可以改变事务上下文122，以增加另一个服务器B128，或许包括位于该服务器的任何一个同步对象和资源132。这样，本发明就提供了一种将服务器B纳入准备环中的机制。在活动和准备阶段期间还可以增加多个服务器。事务上下文通常不易被客户应用程序直接改变。而是，当应用程序调用其它J2EE组件时，J2EE容器将向事务注册附加同步对象或者征召附加XA资源对象；例如(1)当应用程序调用EJB时，EJB容器将向代表EJB的事务管理器注册同步对象，或者(2)当应用程序经由JDBC访问数据库时，Weblogic连接池将向事务管理器征召与数据库事件关联的XA资源。

本领域熟练技术人员将会明白，尽管第一服务器1108在图2中被标识为事务的协调器，但是任何一个服务器都可以承担这一给定事务的任务，并且可以使用各种不同方式选择被选作事务协调器的服务器，所述各种不同方式包括只选择客户所接触的第一服务器。事务协调器可以参与或者不参与提供供事务使用的实际资源。由此得到的本发明特征之一是可以修改客户应用程序以在任何时间点改变事务上下文，并立即实现同步对象或者资源的改变。例如，如果客户应用程序是EJB，则可以在准备或提交阶段期间修改事务上下文，将不同资源包含到不同服务器上，并且把这些资源动态地输入到处理链中。这允许在修改客户应用程序时有极大的灵活性。

图3显示了供本发明使用的典型客户服务器系统。共同称之为客户应用程序的远程装置或应用程序202与应用程序服务器204通信，特别是与担任应用程序服务器宿主的应用程序通信。在客户端，客户应用程序使用事务管理器206发送和接收到达服务器(或者到达许多服务器)的事务208。同样，在服务器端，事务管理器210用客户处理事务。在一个实施例中，服务器还可以包含：一个事务协调器214，用于协调事务提交处理；子协调器216，用于参与事务以及执行各个阶段的提交处理，其中对于向本地事务管理器注册的同步和XA资源对象进行提交处理；和事务日志器218，用于记录事务。当创建事务和处理事务时，将其记录到事务日志220中，用于日后审计、引用或者回退目的。本发明提供了允许特性与每个事务关联的事务管理器。客户或者服务器应用程序可以在传送事务222以及由此反应时分析这些特性。

图4显示了本发明实施例的各种事务的图示。图4显示了事务寿命周期的各种状态或者阶段，包括活动302、预准备306、准备308、记录310和提交312状态。在任何事务寿命周期期间，存在几个状态转换，包括活动、切换、预准备、准备、记录和提交状态之间的转换。在活动状态，运行于客户上的应用程序或者应用程序码被设计成在事务的活动执行期间接触几个服务器。客户负责记忆哪些服务器被接触以及对待事务的某些其它细节。根据本发明的一个实施例，所接触的第一服务器被设计为“提交服务器”或者事务协调器。当客户调用“提交”时，将提交事务的实际职责授权和移交给提交服务器。提交服务器除了负责处理提交的实事外，它还是一个常规服务器，在许多事件中，任何一个服务器可以承担提交服务器的任务，哪个服务器实际结束其职责(由此成为提交服务器)取决于实际实施。

应用程序服务器通常支持各种应用程序类型和事务类型。J2EE顺从应用程序服务器应当支持EJB和RMI应用程序。根据应用程序类型，可以使用各种事务处理方法。Weblogic服务器产品是一个这样的应用程序服务器产品，并且为了图示说明的目的，在本文中经常描述其实施。本领域熟练技术人员将会明白，本发明提供的系统和方法同样可以与其它事务处理系统一起使用，以及与其它类型的应用服务器一起使用。

图5示出了使用同步回退处理事务的本发明实施例的事务系统。当客户602试图通信或者处理事务时，可以接触多个服务器604、606、608，以确定哪一个服务器将实际处理事务。根据实施，选择一个服务器充当提交服务器/事务协调器，而其它服务器仅被视为参与服务器。为了说明目的，图5中只示出了单个提交服务器和两个参与服务器，尽管人们将会明白在真实情况中可以使用许多服务器(并且非常可能用来提供可用性)。同样，尽管显示了一个指定的提交服务器和参与服务器，但是在另一个实施例中，多个服务器中的每个服务器可以充当提交服务器，或者仅充当参与服务器。本发明提供的系统对于所使用的服务器数量和类型是灵活的。一旦作出选择，提交服务器就负责处置提交处理。事务处理仅仅通过客户602与提交服务器604之间的通信来处置，而不需要客户与参与服务器606之间的其它通信。提交服务器本身与参与服务器606(或服务器606、608)一起处置事务处置，并且经由预准备、准备、记录和提交步骤移动事务。当提交处理完成后，提交服务器将提交返回到客户。在准备阶段期间的任何时候以及在回退之前，附加服务器或者参与者可以被插入到事务处理中。

同步回退的典型实例

通过考虑包括多个子协调器(服务器)及其同步对象的一个事务的典型实例，可以说明上述处理。一个典型事务通过五个不同阶段进行：

1.活动阶段。

2.调用事务提交。

3.预准备阶段(该阶段包括同步回退的调用，即仅仅是完成前的同步，但不调用任何资源)。

4.准备阶段(该阶段仅包括调用资源，但不同步回退)。

5.提交阶段(该阶段也仅仅包含调用资源，但不同步回退)。

在步骤3的预准备阶段期间，新同步对象可以向事务注册。还可以在预准备阶段增加新资源，使其参与事务。在步骤4和步骤5期间调用这些资源。通常增加资源，但不从事务中删除资源。新的子协调器(即服务器)可以在预准备阶段参与事务。

例如，如果考虑存在一个客户和三个服务器S1、S2、S3的情况，则存在三个同步对象，即服务器S1上的Sync1，服务器2上的Sync2，服务器3上的Sync3；以及三个资源对象，即S1上的r1，S2上的r2和S3上的r3。如果客户启动或开始事务T1，并且事务T1传播到服务器S1，那么根据本发明一个实施例，服务器S1将成为该事务的提交服务器/事务协调器。其它实施例和实施可以使用从多个可用服务器选择事务协调器的替代机制。在事务T1的活动阶段，我们有以下状态信息：

当前参与事务T1的子协调器(服务器)： S2

向事务T1注册的同步对象：Sync1(来自服务器S1)，Sync2(来自服务器S2)

参与事务T1的资源：r1(来自服务器S1)，r2(来自服务器S2)。

当客户以后调用一个T1.commit()或等同功能，以提交事务时，以下事件序列发生：

1.提交移交给协调器，服务器S1。

2.服务器S1执行预准备阶段。服务器S1调用本地注册的同步回退：Sync1。服务器S1将开始准备请求发送给链中的第一子协调器：S2。

3.服务器S2执行预准备阶段。服务器S2调用本地注册的同步回退的Synchronization.beforeCompletion：Sync2。Sync2.beforeCompletion功能调用新服务器S3上的EJB。EJB的商务方法调用新资源r3。同时，服务器S3上的EJB容器还注册新的统统对象Sync3(在服务器S3上)。

作为结果，事务的状态信息目前改变如下：

当前正在参与事务T1的子协调器(服务器)：S2，S3

现在向T1注册的同步对象：Sync1(来自服务器S1)，Sync2(来自S2)，Sync3(来自服务器S3)

现在参与事务T1的资源：r1(来自服务器S1)，r2(来自服务器S2)，r3(来自服务器S3)。

服务器S2现在已经完成了它自己的同步回退。服务器S2沿着链把预准备请求传送到下一个子协调器，即服务器S3。需要注意的是，当服务器S2首先进入它的准备阶段时，它是链中的最后的子协调器，但现在不是，服务器S3才是现在的链中的最后子协调器。

4.服务器S3现在执行预准备阶段。服务器S3调用本地注册的同步回退：Sync3。服务器S3确定它是链中真正的最后子协调器，由于目前存在链，因此把一个预准备答复回送给事务协调器，即服务器S1。

5.服务器(在该事件中还是事务协调器)S1得知预准备阶段被执行。然后可以前进到准备以及随后的提交阶段。

图6图示说明了显示本发明实施例的同步回退处理的步骤的流程图。在步骤702，客户或者客户应用程序准备一个用于处理的事务。在活动阶段期间(步骤704)，注册将要参与事务处理的各种同步对象、资源或服务器(步骤706)。当调用事务提交时(步骤707)，又调用每个同步对象或资源(步骤708)。在任何时候，可以修改同步对象的目录，把诸如参与服务器的资源添加到回退环中(步骤710)。当当前目录中的所有同步对象已经返回它们的回退时(步骤712)，提交事务(步骤714)。

在beforeCompletion期间对调用bean的bean的支持

EJB和JTA规范都没有澄清如何处理这样一种情况：即bean的beforeCompletion或ejbStore方法(准备前调用)调用另一个其beforeCompletion和/或ejbStore方法已经被调用的bean。本发明支持多个服务器上的这样一种情况。

图7至图14图示说明了根据可与Weblogic服务器一起使用的特定实施例，与同步回退处理的各个阶段相关联的寿命周期；本领域的熟练技术人员将会明白，在本发明精神和范围之内，其它寿命周期和实施例也可以用来提供同步回退。图7显示了本发明实施例的开始事务寿命周期的图示。如图7所示，处理开始于在事务管理器804上接收的事务请求。事务管理器804调用协调器定位器805去选择一个事务协调器806。事务协调器806接收一个事务标识符，并将该标识符与新事务830相关联。该请求被分配给线程的一个池(pool)，并由此返回到事务管理器804。后续请求被分配给与该池不同的线程。

图8显示了本发明一个实施例的事务传播寿命周期的图示。如图8所示，客户应用程序802对本地(客户)Java虚拟机(RJVM)807进行远程方法调度，用于对服务器通信。客户事务管理器804拦截该请求并经由服务器RJVM808将该请求传送到服务器事务管理器810。服务器事务管理器810负责调用服务器应用程序812上的方法。当从服务器应用程序812接收一个答复时，服务器事务管理器810又负责经由客户和服务器RJVM把答复传送到客户事务管理器804。客户事务管理器804将答复返回到客户应用程序802。

图9显示了本发明实施例的提交寿命周期的图示。如图9所示，事务管理器804接收一个提交。该提交被传送到事务协调器806进行处理。当该提交完成时，将其返回到事务管理器804。

图10显示了本发明实施例的预准备阶段寿命周期的图示，显示了同步对象是如何被添加到beforeCompletion环中。如图10所示，事务协调器806采用对第一子协调器814的startPreoare调用启动预准备处理。子协调器负责事务通过beforeCompletion阶段。在beforeCompletion阶段完成之前的任何时候，同步对象816可以被调加到环中。当添加了所有同步对象时，第二子协调器818同时对所有同步对象820起作用。然后把PrePreare确认返回到事务协调器806。本领域熟练技术人员将会明白，在图10所示的寿命周期中以及下文所述的其它寿命周期中，第一和第二子协调器可以是同一实体。同样，第一和第二组同步对象可以是相同的，因为它们也许是XA资源对象的第一和第二组。本领域熟练技术人员还将会明白，尽管在这里给出的实例中仅显示了两个子协调器或者两组资源对象，但是本发明允许多个子协调器和多组同步对象和资源被同时包含在事务提交处理中。该方法主张的子协调器和同步对象使协调器通信交换的数量最小。

图11显示了本发明实施例的使用XAR资源对象的准备阶段寿命周期的图示。如图11所示，事务协调器806采用对第一协调器814的startPrepare调用。子协调器(或多个子协调器)负责准备应付第一组XAR资源对象817的事务。与此同时，事务协调器可以发送对第二子协调器818的startPrepare调用，以准备应付第二组XAR资源对象821的事务。当准备了每个XAR资源对象时，将一个确认返回到事务协调器896。

图12显示了提交阶段寿命周期的图示。如图12所示，事务协调器806首先刷新事务日志。把startCommit调用发送到第一子协调器814。第一子协调器发出一个对第一组XAR资源对象817的提交。与此同时，该事务协调器可以把startCommit发送给子协调器818。第二子协调器发出一个对XAR资源对象821的提交。第二子协调器发出一个对第二组XAR资源对象821的提交。当这两个提交完成时，向协调器806发送一个确认。

图13显示了本发明实施例的返回寿命周期的图示。如图13所示，当系统希望执行返回时，事务协调器806把statrRollback发送到第一协调器814。协调器负责执行离开第一组XAR资源对象817的返回。与此同时，系统经由第二子协调器向第二组XAR资源对象821发出一个startRollback命令，由此可以在第二组XAR资源对象821上执行返回。当两个返回都完成时，把一个确认返回到事务协调器806。

图14显示了本发明实施例的恢复寿命周期的图示。如图14所示，恢复处理通过来自事务协调器806的请求启动，以访问事务恢复日志。当事务协调器806向子协调器814发出一个startRecovery请求以执行恢复时，子协调器使用事务恢复日志中的信息执行XAR资源对象组的恢复。子协调器814使用事务标识符正确地标识每个恢复，并且把该事务标识符返回到事务协调器806。事务协调器806然后向子协调器814发送一个返回请求。

EJB应用程序中的事务

图15显示了如何处理EJB客户应用程序与服务器应用程序之间的事务。如图15所示，EJB客户应用程序402使用EJB容器406把事务404传送到服务器应用程序410。加入本发明的应用程序服务器支持EJB应用程序中的两类事务：容器管理的事务和bean管理的事务。

在容器管理的事务中，服务器EJB容器负责管理事务定界。EJB部署描述符中的事务属性被用来确定服务器EJB容器如何用每个方法调用来处理事务。在bean管理的事务中，EJB本身管理事务界定。EJB对UserTransaction对象进行显性方法调度以开始提交，如果需要，还返回事务。事务事件的序列在容器管理与bean管理的事务之间是不同的。对于带有容器管理事务的EJB应用程序，一个基本事务按以下方式工作：

·在EJB部署描述符中，bean供应者或者应用程序装配器指定容器管理定界的事务类型。

·在EJB部署描述符中，bean供应者或者应用程序装配器为EJB指定默认事务属性，它通常是以下设置之一：“NotSupported”，“Required”。“Supports”，“RequiresNew”，“Mandatory”或者“Never”。在EJB部署描述符中，bean供应者或者应用程序装配器为一个或多个方法随意地指定事务属性。

·当客户应用程序402在EJB中调用方法时，EJB容器为该方法检验部署描述符中的事务属性设置。如果没有为该方法指定设置，则EJB使用该EJB的默认事务属性设置。

·EJB容器406根据可应用的事务属性设置采取适当行动。例如，如果事物属性设置是“Required”，则EJB容器调用现存事务上下文内的方法，或者，如果客户未用事务上下文调用，则EJB容器在执行该方法之前开始一个新事务。

·在另一个实例中，如果事务属性设置是“Mandatory”，则EJB容器调用现存事务上下文中的方法。如果客户未用事务上下文调用，则EJB容器丢弃异常错误。

·在商务方法408的调用期间，如果确定需要返回，则商务方法调用EJB返回方法，通知EJB容器该事务在方法将在调用结束时返回。

·在方法执行结束和巴结果发送给客户之前，EJB容器完成事务，这是通过在服务器应用程序410上提交事务(在此情况下，可以把事务写入事务日志412)或者返回事务实现的。

对于具有bean管理事务定界的EJB应用程序，基本事务以下述方式工作：

·在EJB部署描述符中，bean供应者或者应用程序装配器指定bean管理定界的事务类型。

·客户应用程序402使用JNDI获取对服务器域的UserTransaction对象的引用。

·客户应用程序402开始一个使用UserTransaction.begin方法的事务，并且经过EJB容器发送一个请求给EJB。EJB上的所有操作在事务范围内运行。

·如果对这些操作任何一个的调用出现异常(明示或者作为通信失败的结果)，则可以捕获该异常并且可以返回该事务

(UserTransaction.rollback)。

·如果无异常出现，则客户向使用UserTransaction.commit方法的服务器应用程序410提交当前事务。该方法结束事务并开始操作的处理。只有当事务中的所有参与者都同意提交时才提交该事务。

·UserTranaction.commit方法使EJB容器调用事务管理器完成该事务。

·事务管理器负责与资源管理器协调，以更新任何一个数据库。

事务样本EJB码

以下部分提供了依据EJB应用程序的类别的样品码片段的走查。码片段展示了为bean管理事务定界利用UserTransaction对象的情况。该bean的部署描述符指定了事务定界的事务类型。

事务软件包首先必须被输入和/或更新。列表1显示了输入事务必须的软件包的样本码。

列表1

import javax.naming.^*；

import javax.transaction.UserTransaction；

import javax.transaction.SystemException

import javax.transaction.HeuristicMixedException

import javax.transaction.HeuristicRollbackException

import javax.transaction.NotSupportedException

import javax.transaction.RollbackException

import javax.transaction.IllegalStateException

import javax.transaction.SecurityException

import java.sql.^*；

import java.util.^*；

import weblogic.jndi.^*；

在输入这些类之后，将UserTransaction对象的事件初始化到零。下一步骤包括使用JNDI返回对象参考。列表2显示了使用JNDI查找对象参考的一个实例。

列表2

context ctx＝null

Hashtable env＝new Hashtable()

env.put(context.INITIAL_CONTEXT_FACTORY，“weblogic.jndi.WLInitialCont extFactory”)；

env.put(Context.PROVIDER_URL，“t3：//localhost：7001”)；

env.put(Context.SECURITY_PRINCIPAL，“Fred”)；

env.put(Context.SECURITY_CREDENTIALS，“secret”)；

ctx＝nexInitialContext(env)；

UserTransaction tx＝(UserTransaction)

ctx.lookup(“javax.transaction.UserTransaction”)；

随后必须生成或者开始事务。列表3显示了通过得到UserTransaction对象并调用事务开始方法来开始一个事务。该方法调用后以及完成事务之前出现的数据库操作存在于这些事务的范围之内。

列表3

UserTransaction tx＝(UserTransaction)

ctx.lookup(“javax.transaction.UserTransaction”)；

tx.begin()；

EJB实施中的最后步骤是完成事务。列表4显示了根据在任何一个数据库操作期间是否丢弃一个异常来完成事务的代码，该数据库操作是试图在事务范围之内进行的：

列表4

tx.commit()

//or：

tx.rollback()；

如果在任何数据库操作期间抛出异常，则应用程序调用java.transaction.UserTransaction.rollback()方法来回退事务。

如果没有抛出异常，则应用程序调用javax.Transaction.UserTransaction.commit()方法，以试图在所有数据库操作成功完成之后提交事务。调用该方法结束事务并开始操作的处理，使Weblogic服务器EJB容器调用事务管理器王城事务。只有当事务的参与者都同意提交时才提交事务。

Weblogic服务器RMI应用程序中的事务

图16说明了事务如何在RMI应用程序中工作。对于RMI客户和服务器应用程序，基本事务按以下方式工作：

·应用程序502使用JNDI将对象参考返回到服务器域的UserTransaction对象506。

·获得对象参考导致产生应用程序与该对象之间的一个对话状态。在完成(即提交或者返回)事务504之前，该对话状态一直持续。RMI对象一旦被例示，就存储器中保持活动状态，直至它们被释放，通常是在服务器停机期间进行释放。

·客户应用程序开始一个使用UserTransactin.begin方法的事务，并把请求发送给服务器应用程序。

·服务器应用程序上的所有操作在事务范围之内执行。

·如果对这些操作的任何一个的调用出现异常(明示或者作为通信失败的结果)，则可以捕获该异常并可以返回该事务(UserTransaction.rollback)。

·如果没有异常出现，则客户应用程序提交使用UserTransaction.commit方法的当前事务。该方法结束事务并开始操作的处理。只有当事务的所有参与者都同意提交时，才提交事务。

·UserTransaction.commit方法使服务器调用事务管理器完成该事务。

·事务管理器负责与资源管理器协调更新任何数据库512。

事务样本RMI码

该部分提供了来自RMI应用程序中的类的样本码片段的走查。码片段演示了使用RMI事务的UserTransaction对象的情况。

此外，作为初始步骤，需要时必须输入和/或更新程序包。列表5显示了输入必要的程序包。

列表5

import javax.naming.^*；

import javax.rmi.^*；

import javax.transaction.UserTransaction；

import javax.transaction.SystemException；

import javax.transaction.HeuristicMixedException；

import javax.transaction.HeuristicRollbackException；

import javax.transaction.NotSupportedException；

import javax.transaction.RollbackException；

import javax.transaction.IllegalStateException；

import javax.transaction.SecurityException；

import java.sql.^*；

import java.util.^*；

import weblogic.jndi.^*；

输入这些类后，把UserTransaction对象的事件初始化为零。

JNDI用来吧对象参考返回到UserTransaction对象。列表6显示了搜索JNDI树，把对象参考返回到用于适当Weblogic Server域的UserTransaction对象的情况。

获得对象参考导致产生应用程序与该对象之间的对话状态。在完成事务(提交或返回)之前，该对话状态一直持续。一旦RMI对象被例示，就在存储器中保持其活动状态，直至它们被释放。

列表6

context ctx＝null；

Hashtable env＝new Hashtable()；

env.put(context.INITIAL_CONTEXT_FACTORY，“weblogic.jndi.WLInitialContFactory”)；

//parameters for the WebLogic Server.

//Substitute the correct hostname，port number

//user name，and password for your enviroment：

env.put(context.PROVIDER_URL，“t3：//localhost：7001”)；

env.put(Context.SECURITY_PRINCIPAL，“Fred”)；

env.put(context.SECURITY_CREDENTIALS，“secret”)；

ctx＝new InitialContext(env)；

UserTransaction tx＝(UserTransaction)

ctx.lookup(“javax.transaction.UserTranaction.”)；

然后生成或开始事务。列表7显示通过调用javax.transaction.UsetTransaction.beging()方法开始事务。该方法调用后以及完成事务前发生的数据库操作存在于该事务范围之内。

列表7

UserTransaction tx＝(UserTransaction)

ctx.lookup(“javax.transaction.UserTransaction”)；

tx.begin()；

completing a Transaction

如同EJB实施一样，事务处理中的最后步骤是完成事务。列表8显示了根据是否丢弃异常完成事务，其中在该事务范围之内试图进行任何一个数据库操作期间进行所述丢弃：

列表8

tx.commit()

//or：

tx.rollback()；

如果在任何一个数据库操作期间抛出异常，则应用程序调用javax.transaction.UserTransaction.rollback()方法。

若未抛出异常，则应用程序调用javax.transaction.UserTransaction.commit()方法，以试图在成功完成所有数据库操作之后提交事务。调用该方法导致结束事务并开始操作的处理，使WebLogic服务器调用事务管理器完成事务。只有当事务的所有参与者都同意提交时，才提交事务。

本发明的以上说明用于图示说明的目的，而不是打算用来穷举或者把本发明限制到公开的精确形式。显然，本领域熟练技术人员将会明白许多修改和变化。选择和描述诸多实施例是为了最好地解释本发明原理和实际应用，从而使本发明的熟练技术人员理解适合于特定预期应用的不同实施例以及具有各种修改的本发明。本发明的范围由以下权利要求和其等同物定义。

Claims

1、一种将事务回退与事务完成同步的事务处理系统，包括：

多个可关联于一个事务的同步对象和资源；

一个事务协调器，为一个特定事务注册至少一个或多个事务子协调器的组，以及同步对象回退和资源的选择，以参与该特定事务；

其中，在提交事务之前可以修改该事务子协调器组，以反映参与特定事务的同步对象回退和资源的选择的变化。

2、根据权利要求1所述的系统，还包括多个用于提供同步对象和资源的服务器，其中所述多个服务器之一被选作事务协调器。

3、根据权利要求2所述的系统，其中第一服务器上的事务协调器采用对第二服务器上的事务子协调器的一个开始预准备调用来启动事务预准备处理，其中事务子协调器负责处理整个事务预准备阶段的事务。

4、根据权利要求3所述的系统，其中在事务预准备阶段完成之前的任何时候，注册第二服务器上的附加资源与参与特定事务的同步对象回退和资源的选择，然后把一个预准备确认返回到事务协调器。

5、一种将事务回退与事务完成同步的事务处理方法，包括以下步骤：

提供可关联于一个事务的多个同步对象和资源；

在事务协调器上，为一个特定事务注册至少一个或多个事务子协调器的组，以及同步对象回退和资源的选择，以参与该特定事务；

6、根据权利要求5所述的方法，还包括步骤：

选择多个服务器之一作为事务协调器。

7、根据权利要求6所述的方法，其中所述的注册步骤包括以下步骤：

用对第二服务器上的事务子协调器的开始预准备调用，启动事务协调器上的事务预准备处理；

在事务子协调器上处理整个事务预准备阶段的事务。

8、根据权利要求7所述的方法，其中所述的注册步骤包括：

在事务预准备阶段完成之前的任何时候，注册第二服务器上的附加资源与同步对象回退和资源的选择，以参与该特定事务；和

把预准备确认返回到事务协调器。

9、一种将回退与事务完成相同步的事务处理系统，包括运行时允许系统执行以下步骤的指令：

提供多个服务事务的同步对象；

经由一个或多个事务子协调器将来自事务协调器的事务请求传送到所述多个同步对象，包括

将事务请求传送给第一子协调器上的第一组所述多个同步对象，

将事务请求传送给第二子协调器上的第二组所述多个同步对象；以及

在提交事务之前，把来自第二组同步对象的回退与来自第一组同步对象的回退相同步。

10、根据权利要求9所述的系统，还包括提供同步对象和资源的多个服务器，其中所述多个服务器之一被选作事务协调器。

11、根据权利要求10所述的系统，其中第一服务器上的事务协调器借助对第二服务器上的第一事务子协调器的开始预准备调用来启动事务预准备处理，其中第一事务子协调器负责处理包括第三服务器的第二事务子协调器的整个事务预准备阶段的事务。

12、根据权利要求11所述的系统，其中，在事务预准备阶段之前的任何时间，注册第二或第三服务器上的附加资源与同步对象回退和资源的选择，以参与该特定事务，然后把预准备确认返回到事务子协调器。

13、一种将回退与事务完成相同步的事务处理方法，包括以下步骤：

提供多个服务事务的同步对象；

经由一个或多个事务子协调器将来自事务协调器的事务请求传送到所述多个同步对象，包括：

14、根据权利要求13所述的方法，还包括步骤：

把所述多个服务器之一选作事务协调器。

15、根据权利要求14所述的方法，其中所述注册步骤包括以下步骤：

借助对第二服务器上的第一事务子协调器的开始预准备调用来启动事务协调器上的事务预准备处理；以及

在第一事务子协调器上，处理包括第三服务器的第二事务子协调器的整个事务预准备阶段的事务。

16、根据权利要求15所述的方法，其中，所述同步步骤包括以下步骤：

在事务预准备阶段之前的任何时间，注册第二或第三服务器上的附加资源与同步对象回退和资源的选择，以参与该特定事务；

把预准备确认返回到事务子协调器。

17、一种将回退与事务完成相同步的事务处理方法，包括以下步骤：

准备用于处理的事务；

注册参与事务处理的同步对象和资源的初始组；

调用一个事务提交；

预准备所述事务，包括以下步骤

检查参与所述事务的附加同步对象或者资源，

把所述附加同步对象或者所述附加资源的至少之一添加到所述已注册同步对象和资源组上，以及

调用对所述已注册同步对象和资源组中的同步对象的同步对象回退；

准备所述已注册同步对象和资源组中的资源；和

提交已经返回的已注册同步对象和资源组中的资源。

18、一种将回退与事务完成相同步的事务处理方法，包括以下步骤：

准备用于处理的事务；

注册参与事务处理的同步对象和资源的初始组；

调用一个事务提交；

预准备所述事务，包括以下步骤：

把附加同步对象或者所述资源的至少一个添加到所述的已注册同步对象和/或资源组上，和

准备所述已注册同步对象和资源组中的资源；和

提交已经返回的已注册同步对象和资源组中的资源。

19、一种将回退与事务完成相同步的事务处理方法，包括以下步骤：

提供多个服务事务的同步对象和资源；

经由一个或多个事务子协调器将来自事务协调器的事务请求传送到所述多个同步对象和所述资源，包括

将事务请求传送给第一子协调器上的第一组所述多个同步对象和资源，

将事务请求传送给第二子协调器上的第二组所述多个同步对象和资源；和