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

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 等。关心软件技术和相关工具的动态，将其中成熟的技术和工具应用到实际的项目之中。关心开源软件的发展动态以及软件过程和敏捷开发的实践探索。