xa是x／open dtp定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。xa接口函数则由数据库厂商提供。

　　在谈到xa规范之前，必须首先了解分布式事务处理（distributed transaction processing）的概念。transaction，即事务，指一个程序或程序段，在一个或多个资源如数据库或文件上为完成某些功能的执行过程的集合。

分布式事务处理是指一个事务可能涉及多个数据库操作，分布式事务处理的关键是必须有一种方法可以管理事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。

x／open组织（即现在的open group）定义了分布式事务处理模型。x／open dtp模型（1994）包括应用程序（ap）、事务管理器（tm）、资源管理器（rm）、通信资源管理器（crm）四部分。一般，常见的事务管理器（tm）是交易中间件，常见的资源管理器（rm）是数据库，常见的通信资源管理器（crm）是消息中间件。为表述方便起见，在本文中直接以其常见表现形式进行描述。

通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。

所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。

一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个dtp环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。

xa规范的基础是两阶段提交协议。

在第一阶段，交易中间件请求所有相关数据库准备提交（预提交）各自的事务分支，以确认是否所有相关数据库都可以提交各自的事务分支。当某一数据库收到预提交后，如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来，并给交易中间件一个同意提交的应答，此时数据库将不能再在该事务分支中加入任何操作，但此时数据库并没有真正提交该事务，数据库对共享资源的操作还未释放（处于上锁状态）。如果由于某种原因数据库无法提交属于自己的事务分支，它将回滚自己的所有操作，释放对共享资源上的锁，并返回给交易中间件失败应答。

在第二阶段，交易中间件审查所有数据库返回的预提交结果，如所有数据库都可以提交，交易中间件将要求所有数据库做正式提交，这样该全局事务被提交。而如果有任一数据库预提交返回失败，交易中间件将要求所有其它数据库回滚其操作，这样该全局事务被回滚。

以一个全局事务为例，ap首先通知交易中间件开始一个全局事务，交易中间件通过xa接口函数通知数据库开始事务，然后ap可以对数据库管理的资源进行操作，数据库系统记录事务对本地资源的所有操作。操作完成后交易中间件通过xa接口函数通知数据库操作完成。交易中间件负责记录ap操作过哪些数据库（事务分支）。ap根据情况通知交易中间件提交该全局事务，交易中间件会通过xa接口函数要求各个数据库做预提交，所有数据库返回成功后要求各个数据库做正式提交，此时一笔全局事务结束。

xa规范对应用来说，最大好处在于事务的完整性由交易中间件和数据库通过xa接口控制，ap只需要关注与数据库的应用逻辑的处理，而无需过多关心事务的完整性，应用设计开发会简化很多。

具体来说，如果没有交易中间件，应用系统需要在程序内部直接通知数据库开始、结束和提交事务，当出现异常情况时必须由专门的程序对数据库进行反向操作才能完成回滚。如果是有很多事务分支的全局事务，回滚时情况将变得异常复杂。而使用xa接口，则全局事务的提交是由交易中间件控制，应用程序只需通知交易中间件提交或回滚事务，就可以控制整个事务（可能涉及多个异地的数据库）的全部提交或回滚，应用程序完全不用考虑冲正逻辑。

http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0505weber/index.html
这篇文章里面有非常详细的代码描绘，值得参考。

http://www.cnblogs.com/sunwei2012/archive/2010/01/08/1642295.html
这也是一篇不错的文章。