XA 两阶段详细解说 详解

具体出处我也不知道，这个是我很早以前收藏的。

XA接口标准是事务处理系统与数据库服务器的事务管理接口，CICS事务所作的数据库修改在事务提交（COMMIT）或回撤（ROLLBACK）时由事务处理器通过XA接口向数据库服务器发出提交或回撤请求。由于网络通讯故障随时可能发生，任何发出请求后等待回应的程序都会有失去联系的危险。这种危险发生在发出请求之后，服务器返回应答之前，如果在这个期间网络通讯发生故障，发出请求一方无法收到回应，于是无法判断服务器是否已经成功地处理请求，因为收不到回应可能是请求没有成功地发送到服务器，也可能是服务器处理完成后的回应无法传回请求方。这段时间称为网络通讯的危险期（In-doubt Time）。

无论如何，网络通讯危险期总是存在的，两阶段提交是为了解决这个问题的一种办法。一阶段提交就是事务处理器向数据库服务器发出提交请求，然后等待数据库服务器的回应，收到回应后完成事务的提交，或者服务器返回提交失败的结果就回撤事务。危险期从发出请求开始，到收到回应结束，这段时间中数据库完成数据的修改、日志记录等处理，处理越复杂，危险期就越长。
两阶段提交把事务提交分成两个阶段，第一阶段，事务处理器向数据库服务器发出 " 准备提交 " 请求，数据库收到请求后执行相同的数据修改和日志记录等处理，不同的是处理完成后只是把事务的状态改成 " 可以提交 " ，然后把结果返回给事务处理器。事务处理器收到回应后进入第二阶段，如果在第一阶段内的危险期中发生了故障，事务处理器收不到回应，则认为事务失败，回撤事务。数据库服务器收不到第二阶段的确认提交请求，把 " 可以提交 " 的事务回撤。
两阶段的第二阶段中事务处理器向数据库服务器发出 " 确认提交 " 请求，数据库服务器把事务的 " 可以提交 " 状态改为 " 提交完成 " 状态，然后返回应答。从严格意义上说，两阶段提交并没有完全解决网络通讯危险期的问题，但因为第二阶段的处理很简单，只是修改了事务的状态，与第一阶段相比其处理时间极短，所以危险期极短，发生事务提交故障的可能性几乎不存在。
很多人会问：如果事务处理器只管理一个数据库资源，是不是可以只用一阶段提交的XA接口，如果要管理两个或以上的数据库资源就要使用两阶段提交的XA接口？答案是否定的，用不用两阶段提交不是取决于数据库资源的个数，而是取决于通讯危险期的长短，即事务处理器与数据库服务器间的网络通讯质量。如果事务处理器通过XA接口连接远程数据库，网络通讯质量不高，为了保证事务的完整性，即使只连接一个数据库也应该使用两阶段提交接口。如果事务处理通过XA接口连接局域网上的数据库服务器，连接一个或多个数据库都可以使用一阶段提交接口。
管理多个数据资源的事务处理器中发生的事务可以修改所有相连的数据库，事务提交被分解为多个子事务，分别向各个数据库发出提交请求，这种事务也被称为全局事务。管理单个数据资源的事务处理器中发生的事务只能修改一个数据库，因而不会被分解，这种事务被称为局部事务。虽然多数关于两阶段提交的资料都以全局事务的运作来说明两阶段提交的原理，但两阶段提交与全局事务并没有直接的联系。
同一个事务处理器连接的多个数据资源要使用类型相同的XA接口，不能一些使用一阶段提交接口，另一些却使用两阶段提交接口，如果这样配置，全局事务的提交会失败。两阶段提交的处理过程比一阶段提交复杂，所以效率也较低，大多数企业事务处理系统的事务处理器与数据库服务器运行在同一个计算中心内，以高速而稳定的网络相连接，甚至运行在同一台机器上，这种配置最好使用一阶段提交接口。
这时会引出第二个问题：一台CICS服务器上的应用要连接一个本地的数据库（指运行在同一台机器上或连接在同一个高速的局域网上的数据库），同时也要通过不稳定的网络连接另一个远程数据库，该如何保证CICS应用执行的事务完整性？如果访问远程数据库的响应时间不会过长以至严重地影响整个事务的处理时间，仍然可以采用两阶段提交XA接口。否则应该采用另一种方案，在远程数据库一端安装一个CICS服务器与该数据库通过一阶段提交XA接口相连，本地CICS 服务器上的应用要访问远程数据库时通过CICS间的互连机制向远程CICS服务器发出处理请求，由远程CICS服务器上的程序完成处理，整个事务的完整性由CICS的分布式事务管理机制保证，这就已经超出了XA接口的功能范围了，具体的配置请参阅CICS相关文档CICS Intercommunication Guide 。