1998年底，中国建设银行广东省分行将其储蓄业务处理系统SAV3.0，基于TongLINK 3.4和TongEASY2.5升级到SAV4.0。
　　与以往版本比较，TongLINK 3.4和TongEASY2.5增加了统一管理功能，提供管理应用API，即允许用户将某网络节点设置成管理机，在管理机上可以监控和配置网络中任一节点（包括中心和前端）的TongLINK和 TongEASY。同时，TongLINK 3.4和TongEASY2.5增强了自身的安全管理功能，形成了完整的安全管理体制，包括节点认证、应用认证、数据加密等。
　　除此之外，与以往版本最大的差别在于，TongEASY2.5是一个支持XA规范的版本。中国建设银行广东省分行因此成为第一个在TongEASY上使用XA的成功案例，在整个中国建设银行独树一帜。

XA基础

　　在谈到XA规范之前，必须首先了解分布式事务处理（Distributed Transaction Processing，DTP）的概念。Transaction，即事务，又称之为交易，指一个程序或程序段，在一个或多个资源如数据库或文件上为完成某些功能的执行过程的集合。
　　分布式事务处理是指一个事务可能涉及多个数据库操作，分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。
　　X/Open组织（即现在的Open Group）定义了分布式事务处理模型。X/Open DTP模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。一般，常见的事务管理器（TM）是交易中间件，常见的资源管理器（RM）是数据库，常见的通信资源管理器（CRM）是消息中间件。为表述方便起见，在本文中直接以其常见表现形式进行描述。



　　通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。
　　所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。
　　一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个DTP环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。
　　XA就是X/Open DTP定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。XA接口函数由数据库厂商提供。

XA与两阶段提交协议

　　通常情况下，交易中间件与数据库通过XA 接口规范，使用两阶段提交来完成一个全局事务，XA规范的基础是两阶段提交协议。
　　在第一阶段，交易中间件请求所有相关数据库准备提交（预提交）各自的事务分支，以确认是否所有相关数据库都可以提交各自的事务分支。当某一数据库收到预提交后，如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来，并给交易中间件一个同意提交的应答，此时数据库将不能再在该事务分支中加入任何操作，但此时数据库并没有真正提交该事务，数据库对共享资源的操作还未释放（处于上锁状态）。如果由于某种原因数据库无法提交属于自己的事务分支，它将回滚自己的所有操作，释放对共享资源上的锁，并返回给交易中间件失败应答。
　　在第二阶段，交易中间件审查所有数据库返回的预提交结果，如所有数据库都可以提交，交易中间件将要求所有数据库做正式提交，这样该全局事务被提交。而如果有任一数据库预提交返回失败，交易中间件将要求所有其它数据库回滚其操作，这样该全局事务被回滚。
　　以一个全局事务为例，AP首先通知交易中间件开始一个全局事务，交易中间件通过XA接口函数通知数据库开始事务，然后AP可以对数据库管理的资源进行操作，数据库系统记录事务对本地资源的所有操作。操作完成后交易中间件通过XA接口函数通知数据库操作完成。交易中间件负责记录AP操作过哪些数据库（事务分支）。AP根据情况通知交易中间件提交该全局事务，交易中间件会通过XA接口函数要求各个数据库做预提交，所有数据库返回成功后要求各个数据库做正式提交，此时一笔全局事务结束。
　　XA规范对应用来说，最大好处在于事务的完整性由交易中间件和数据库通过XA接口控制，AP只需要关注与数据库的应用逻辑的处理，而无需过多关心事务的完整性，应用设计开发会简化很多。
　　具体来说，如果没有交易中间件，应用系统需要在程序内部直接通知数据库开始、结束和提交事务，当出现异常情况时必须由专门的程序对数据库进行反向操作才能完成回滚。如果是有很多事务分支的全局事务，回滚时情况将变得异常复杂。而使用XA接口，则全局事务的提交是由交易中间件控制，应用程序只需通知交易中间件提交或回滚事务，就可以控制整个事务（可能涉及多个异地的数据库）的全部提交或回滚，应用程序完全不用考虑冲正逻辑。

两阶段提交协议的一种变例

　　在一个涉及多个数据库的全局事务中，为保证全局事务的完整性，由交易中间件控制数据库做两阶段提交是必要的。但典型的两阶段提交，对数据库来说事务从开始到结束（提交或回滚）时间相对较长，在事务处理期间数据库使用的资源（如逻辑日志、各种锁），直到事务结束时才会释放。因此，使用典型的两阶段提交相对来说会占用更多的资源，在网络条件不是很好，如低速网、网络颠簸频繁，情况会更为严重。
　　当一个全局事务只涉及一个数据库时，有一种优化方式，即一阶段提交。当AP通知交易中间件提交事务时，交易中间件直接要求数据库提交事务，省去两阶段提交中的第一阶段，可以缩短处理一个事务的时间，以提高事务处理的效率。作为两阶段提交的一种特例，与两阶段一样，一阶段提交也是标准的。
　　TongEASY既支持典型的两阶段提交，也支持优化的一阶段提交。由于国内网络状况不够理想，低速网使用面积大，网络瞬间故障频繁，同时有不少应用是架构在一个数据库上，因此一阶段提交在国内目前状况下不失为一种现实选择。中国建设银行广东省分行根据本辖区前端储蓄所与中心之间，网络条件一般（DDN）的情况，且全局事务中只含有一个数据库，选择了TongEASY的优化的一阶段提交。
　　TongEASY的独创性集中体现在一阶段提交的实现方法上。TongEASY的一阶段提交被我们命名为快速XA，一笔普通交易的实际网络传输只有3次（请求、应答、确认，如下图所示），交易结果以前台为准。与典型的两阶段提交或一阶段提交相比，可以有效缩短交易的时间，提高交易处理效率。

　　当因某种原因（如网络颠簸）前端的确认没有发到中心时，中心的TongEASY会自动和前端核对交易结果。TongEASY特有的确认核对机制可以避免可能出现的前后台交易结果不一致的问题。
　　典型的两阶段提交或一阶段提交，在前端发确认时数据库才提交事务，在极端情况下，前端确认丢失而中心核对不到交易结果，数据库中该事务将长时间无法提交，最终造成资源耗尽数据库无法正常工作。为避免这种情况，TongEASY在前端确认超时后，中心无法从前端核对交易结果，将自动提交该交易。TongEASY自动提交某交易后，将该笔交易相关数据上锁，在确认前后台交易结果一致以前，禁止所有涉及该数据的交易以及自动提交交易发起节点发来的所有交易。
　　TongEASY的交易处理的效率高，是用户比较认可的一点。那么，与国外同类产品相比，TongEASY为什么会有如此高的处理效率呢？
　　使用优化的一阶段提交时，一般国外交易中间件的交易结果是以中心为准，正常交易前端发送的确认需要中心的应答，实际网络传输为4次，比TongEASY多出1次，并且没有核对机制。采用这种方式，当某种原因（如暂时的网络故障、数据库故障）使确认没有传到中心，或确认应答没有传到前端，前端会因等待确认超时而出错返回，需人工向中心核对交易结果。由此可见，在网络情况不是很好的情况下，这种方式因网络传输次数多，没有核对机制而使出错的概率增加。TongEASY特有的3次传输过程，首先因减少了传输次数而减少了出错的概率，即使出错，TongEASY的核对机制不需人工干预，又可以恢复绝大多数的错误。

TongEASY的实际工作情况

　　1998年8月，中国建设银行广东省分行在TongEASY上组织开发基于XA接口的储蓄系统SAV4.0，1999年4月开发测试完成，5月在肇庆分行的60个网点运行，日均2万笔交易（其中记入流水的交易8000笔），7月在珠海分行的69个网点运行，日均5万笔交易（其中记入流水的交易2.4万笔），全省推广工作将在1999年10月之前完成。
　　运行储蓄系统SAV4.0的前端储蓄所网点为PC机，运行SCO UNIX3.0、Informix-SE、TongLINK3.4、TongEASY2.5和前端应用程序；中心为HP9000，运行HP-UX10.1、Infrmoix-Online 7.13、TongLINK3.4、TongEASY2.5和中心服务程序等。
　　SAV4.0比原储蓄系统SAV3.0，在系统效率、可靠性等各个方面都有很大的提高。以肇庆分行为例，从5月到7月系统运行两个月来，除去人为原因，没有一笔错帐。
　　事实证明，TongEASY对两阶段提交协议的创造性发展是成功的，为在国内现有应用环境下全面提高应用质量，具有积极的意义。