[发明专利]分布式事务恢复系统和方法

说明书

技术领域

本发明涉及事务可恢复性(transactional recoverability)，具体地，涉及分布式计算环境中的事务可恢复性。

背景技术

除非在此另外指示，否则在本部分中描述的方法不是本申请权利要求的现有技术，并且不因包括在本部分中而承认其为现有技术。

在目前的许多商业企业中，企业应用正借助企业内部或外部存在的许多分布式资源。这些资源可以是数据库、消息传递系统或者甚至可以是向外部世界提供服务的应用。

在许多情况下，期望以事务的方式进行遍及这种系统的更新。这基本意味着所述更新必须符合ACID准则(原子性(atomicity)、一致性、隔离性和持续性)。原子性意味着分布式资源中的改变在所有资源都执行或都不执行。一致性意味着当事务结束时，在这些资源之间的完整性约束必须有效。隔离性意味着事务外部的任何操作都看不到中间状态。持续性意味着如果事务成功结束，则它将持续并且不被撤销。

目前，在企业内常见的几乎所有资源都符合这些准则。如果要求数据库管理系统(DBMS)在单个事务(transaction)中从一个账户取钱并且存入另一账户，那么可以预期该DBMS能够根据上述ACID规则完美地完成这一事务。该DBMS本身对该事务进行完全地控制，它既是事务管理器，也是被事务管理器管理的资源。

如果事务必须跨越多个资源，则情况完全改变。应用服务器变为事务管理器，而所有资源变为该事务管理器的下级(subordinate)。因为事务的整体状态现在分布在所有涉及到的资源管理器上，所以将存在一些时间量，在所述时间量期间整个事务不一致。

所述不一致性不是可以避免的事情，它存在于分布式系统的基本性质中。因此如果执行事务工作或其部分的系统崩溃，则该不一致性将持续。这种情况的一个例子可以是，在一个资源已经进行了它的改变而第二个资源还没有进行改变时，应用服务器崩溃。

为了克服这些问题，可以使用事务恢复(transaction recovery)策略。如果在事务中涉及的系统再次变为可用，则应用服务器中的事务恢复功能会记起向触发该事务的应用承诺过什么。应用服务器与资源检查它们那部分事务的结果，并试图达到一致状态。如果应用服务器不能达到一致状态，则它将所涉及的资源之间的这种不一致性通知给操作者，从而至少标识出问题。

如果在没有事务可恢复功能的情况下使用分布式事务，则客户数据极有可能会被损坏。这就是利用当前的Java^TM应用服务器架构的情况。如在JavaTransaction Processing(Java事务处理)一书中所描述的：“一些应用服务器(目前这主要应用于实验性项目或开源项目，而没有应用于企业级质量服务器)不提供恢复能力，这些应用服务器不应当用于与要求事务的多个可恢复资源交互的应用”。见Mark Little等人的Java Transaction Processing(PrenticeHall PTR 2004)。

实现事务恢复是对应用服务器的根本改变。可以创建并使用新的恢复功能。此外，可以改变实现资源的方式。这可能需要对其他系统进行进一步地修改，所述其它系统例如服务器内的Java^TM消息传递系统提供者(Java^TMMessaging System(JMS)provider)、事务管理器(Transaction Manager，TM)、JDBC(Java^TM Database Connectivity，Java^TM数据库连接)DB(数据库)池服务、以及Java连接器容器(Java Connector Container)。

如果应用服务器和事务管理器(其曾是应用服务器的一部分)一起崩溃，则在事务中曾涉及的资源被单独留下。这种单独的资源是危险的，因为仍然存在未决的(pending)事务：在一段时间后，该资源将会决定是提交(commit)还是回滚(rollback)它所涉及的事务部分。这一决定可能符合也可能不符合事务管理器的原始意图——这就是所谓的启发式决定(heuristic decision)。因此，只要可能就必须避免启发式决定。

分布式计算环境通常包括多个层，其中每层具有一个或多个计算设备。例如，两层架构可以包括客户端层和服务器层，在每层中具有多个客户端设备和多个服务器设备。三层架构可以包括客户端层、应用服务器层和数据库服务器层(同样，在每层中具有多个计算设备)。