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

原文链接：

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

Page 5 of 6

性能和JDBCPersistenceAdapter

ActiveMQ社区的一些人宣称JDBCPersistenceAdapter存在性能问题。然而，很多项目和正式系统使用ActiveMQ和关系数据库。从这些例子中可以获知应该使用一个该适配器的日志（journaled） 版本来提高性能。这对于共享资源模式并不合适（因为日志本身是一个新的事务资源）。然而，关注点仍在JDBCPersistenceAdapter上。事实上有理由认为使用一个共享资源可能会比日志方式有更好的性能。这是一个在Spring和ActiveMQ工程师团队中活跃的研究领域。

另外一个不使用消息机制（多数据库）的共享资源技术是使用Oracle数据库链接特性来把两个数据库模式一起链接在RDBMS平台级别上。这可能会需要应用代码的修改，或者创建同义词，因为指向一个链接数据库的表别名包含链接的名字。

最大努力单阶段提交模式(Best Efforts 1PC pattern)

最大努力单阶段提交模式运用比较普遍，但开发人员必须意识到在某些情况下会出现事务失败。这是一个非XA模式，包含一个同步的单阶段的一些资源的提交。由于未使用2PC，它不可能和XA事务一样安全，但如果参与者认识到其中的设计折衷，那么这个模式通常情况下已经足够好。很多高容量，高并发处理事务系统是这样设计以提高性能。

基本的想法是尽可能的延迟一个事务中资源操作的提交，这样仅有的失败可能是基础设施出问题（而不是业务处理错误）。依赖于这个模式的系统基本上假定系统基础设施的失败很少会发生，这样他们能为了更高的并发处理量而承担这样的失败风险。如果业务处理服务也同样设计为幂等的，那么在实践中很少犯错。

为了帮你更好的理解这个模式和分析失败的后果，我将使用消息驱动数据库更新为例。

这个事务中的两个资源被反复计算。消息事务开始于第一个数据库的操作之前，而以相反的顺序结束（或者提交或者回滚）。所以这个案例中的成功序列和本文开始的时候所列举的例子相同：

1. 开始消息事务
2. 接收消息
3. 开始数据库事务
4. 更新数据库
5. 提交数据库事务
6. 提交消息事物

事实上，前4个步骤地顺序并不重要，除了消息必须在数据库更新之前被接收，而且每个事务必须开始于它所对应的资源被使用之前。所以下面的顺序一样有效：

1. 开始消息事务
2. 开始数据库事务
3. 接收消息
4. 更新数据库
5. 提交数据库事务
6. 提交消息事务

关键是最后两个步骤很重要：他们必须在最后执行。为什么顺序是重要的，主要是技术方面的原因，但顺序本身是由业务需求决定的。顺序告诉你某一个事务性资源在这种情况下是特殊的；它包含了如何进行其他资源的工作。这是一个业务排序：系统不能自动做出辨别（尽管如果两种资源分别是消息和数据库的时候，经常是这个顺序）。顺序很重要的原因在于处理失败回滚。最常见的故障情况下（目前为止）是业务处理的失败（坏数据，编程错误，等等）。在这种情况下，两种事务可以被容易的操控来响应异常和进行回滚。在这种情况下，业务数据的完整性被保留，操作序列类似于本文开头所描述的案例。

by iefreer