开发者应该书写他们自己的事务协调逻辑吗？

Mark Little是Red Hat的JBoss部门的标准主管和开发经理。他把大部分的职业时间都投入到了分布式计算和分布式事务协议上。他是好几个工作组的成员，这些工作组试图为Web服务定义一个事务协议，比如BTP，WS-CAF和WS-TX。

在十二月，Mark发表了博文“大规模分布式事务”。他解释说，由于他过去从事复制（replication）协议方面的工作，他得出一个结论：为了获得性能和可用性，需要牺牲一致性。这与Werner Vogels在QCon伦敦2007大会上的发言一致。

Mark声称：

对事务来说，有一点也是一样的（译注：即和服务实现一样，事物实现也是各异的）：事实上，如果你想将不同的服务和域粘合在一起，在Web服务中这是必须的。在服务边界的背后，它们中的一部分可能并不是使用相同的事务实现。

他指出，其他人比如Pat Helland也考虑过放宽事务能力。Mark用海森堡测不准原理（Heisenberg's Uncertainty Principle）来阐明他的观点： 

你可以知道所有的参与者的任一状态，但不知道何时到达；反之亦然。

他还给我们指出WS-BP规范是WS-CAF（组合应用框架）规范集的一部分:

业务流程事务模型和传统的2PC事务模型的一个关键差异是它假定成功。也就是说BP模型是乐观，它假设失败的案例是少数，在需要情况下可以被处理或者离线解决，或者通过重试（replay）/空操作（void）/补偿（compensation），但不会始终是自动的，经常需要人工交互。

这个方法在Pat用于阐明他的论文的例子中得到回应：

考虑一个买房者以及他和第三方担保（escrow）公司的关系。购买者和第三方担保公司达成一个信任协议。卖家、抵押公司、以及事务中涉及的所有其他方也是如此。

当你签了一份购买一套房子的文件，你并不知道交易的结果。你承认，除非第三方担保公司倒闭你才会是不可靠的。控制决策的唯一方是第三方担保公司。这是一个两方关系的星型（hub-and-spoke）集合，被用于一大群当事人在不使用分布式事务下取得一致意见。

Pat补充：

当你考虑几乎无限规模的情形时，再去回想两方关系就很有意思了。这可以通过从两方试探/取消/确认(就像传统的工作流)逐步进行构造。

Greg Pavlik，也是许多Web服务事务规范的合作者，开始思考不同的方面：

应用系统可能包含协调者的角色，在某种程度上它变得越来越不清晰，为什么协议的必要性要远大于业务逻辑本身？

这里有些需要被应用开发人员理解的模式。它们可能被一些框架支持。但是有一点很明显：事务管理不会在上下文中扮演主要角色。

Mark答复，是的，

[他不]认为分布式ACID事务（译注：原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability）在大规模系统上有很大的前途。

但是，

仍然有一个可靠的协调者，它控制状态转换、在故障和恢复的时候“做正确的事情”。

去年夏天，Juval Löwy ——IDesign.net的首席架构师——在一个播客（podcast）里暗示了相似的结论：

当几个软件代理参与执行一个公共工作单元的时候，重新发明 专用事务协议去完成状态调整不是一个好主意。

查看英文原文： Should developers write their own transaction coordination logic? 译者简介：王志雄，长期从事软件开发工作，项目集中在EAM和设备点检管理领域。2004年转入JAVA领域，曾经在项目中使用过Hibernate、Struts、Spring 等。关心软件技术和相关工具的动态，将其中成熟的技术和工具应用到实际的项目之中。关心开源软件的发展动态以及软件过程和敏捷开发的实践探索。