Spring的分布式事务，使用或不用XA - 2

原文链接：

http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html?page=2

    1. 开始消息事务
    2. 接收消息
    3. 开始数据库事务
    4. 更新数据库, 失败!
    5. 回滚数据库事务
    6. 回滚消息事务

如上的例子中, 消息在最后的回滚动作发生后传回中间件，并在某个时刻被另外一个事务所接收。这通常是好事，否则你可能无法记录失败。(自动重试和异常处理的机制不在本文讨论范围)

上面两个程序流最重要的特征在于它们是原子性的, 形成单个逻辑事务，要么全部成功，要么全部失败。

但究竟怎么保证程序流和上面的两种情况类似呢？必须使用到一些事务资源之间的同步，这样如果一个提交，那么全部提交，反之亦然。由于包含了多个事务资源，所以事务是分布式的，如果不采取同步措施，那么一定不会是原子性的。分布式事务技术和概念上的困难均在于资源之间的同步(或缺少同步)。

下面讨论的前面的3个模式是基于XA协议的。由于这些模式被广泛讨论过，我不会涉及太多的细节。熟悉XA模式的读者可以直接跳到共享事务资源模式（Shared Transaction Resource pattern）。
使用两阶段提交方式的完整XA（Full XA with 2PC）

如果需要‘防弹级别’的保护比如事务需要从服务中断中恢复, 甚至包括服务器崩溃，那么完整XA(Full XA)是你唯一的选择。在这个例子中用来同步事务的共享资源是一个特殊的事务管理器，用来协调使用XA协议的进程的信息。在Java中，从开发者角度来看，协议是通过JTA UserTransaction来暴露的。

做为一个系统接口，XA的能力大部分开发者尚不了解。他们需要知道有这么一个XA，能做什么，有什么代价，如何使用事务资源。代价来自于两阶段提交协议two-phase commit (2PC) ，事务管理器使用该协议来确保所有的资源在事务结束前对处理结果达成一致。

如果是Spring应用，会使用Spring JtaTransactionManager和Spring声明式事务管理(declarative transaction management) 来隐藏底层同步的技术细节。使用XA或不用XA之间的区别仅在于配置工厂资源：数据源（DataSource）实例，和应用程序事务管理器。这篇文档包含一个示范应用（atomikos-db项目）演示了这个配置。数据源（DataSource）实例和事务管理器是仅有的XA-或JTA-相关元素。

想了解示范应用是如何工作的，可以运行com.springsource.open.db下面的单元测试用例。MultipleDataSourceTests类插入数据到两个数据源中，然后使用Spring整合支持功能回滚这个事务，如列表1中所示：

by iefreer