分布式事务.net java SAP答案

【问题标题】：distributed transaction .net java SAP分布式事务.net java SAP
【发布时间】：2012-09-03 02:57:34
【问题描述】：

我使用了几个通过面向服务架构连接的系统，这些系统包括：.NET 技术、Java WebLogic Service 和 SAP RFC。

是否有可能实现跨这些不同技术的分布式事务？比如更新 SAP 失败时，我们需要确保 .NET 和 Java 事务根本不会发生。

非常感谢您的意见，或者您可以指出我们可以在哪里学习基本操作方法？

【问题讨论】：

调用这三个不同服务的驱动程序的语言是什么？
主要是从.NET调用这些服务

标签： java .net transactions soa distributed

【解决方案1】：

我会这样做：

与服务的每次交互都是一个Command，其中定义了execute() 和undo() 方法。
维护一堆命令，成功后推送每个命令。
当命令失败时，即与服务交互失败，从堆栈中弹出每个命令并调用undo()。

不过，您可能会在 .NET 中寻找任何可以开箱即用地提供此功能的 Distributed Transaction API。

【讨论】：

您好维克多，感谢您的快速回复。这是否意味着我们需要手动实现“撤消”方法？ .net、java 或 SAP RFC 中是否有任何现成的 API 将支持此回滚操作并可以与 .net 通信以同步事务的提交/回滚？
服务调用的撤消操作非常特定于该调用，因此任何开箱即用的框架都可能不支持。同样的论点也适用于 SAP 调用。是的，一个框架可以通过提供撤销来处理数据库交互，其中数据库操作的事务将被回滚。让我们看看 C# 专家对任何提供此功能的现有框架的看法...

【解决方案2】：

我不建议在系统之间使用分布式事务，因为它会在它们之间产生大量耦合并增加每个系统的负载，因为它为其他系统持有锁（你可以看到我写的一篇名为 "transactional integration anti-pattern" 的文章）。通常更好的选择，正如 Vikdor 所建议的，使用Saga，您可以手动或通过一些外部协调器（例如使用Orchestration）进行协调。

请注意，补偿逻辑可能无法完全撤消操作（例如，在零售场景中，如果订单导致您达到库存阈值并且从供应商处订购，则取消该订单不必取消您的从您的供应商处订购。此外，您可能无法全额退款等）

【讨论】：

您好 Arnon，非常感谢您的回答。你肯定给了我们一些可以开始学习的材料。我们最近对“回滚”操作有些担心，因为我们不能保证我们的回滚操作会成功。
我有时发现如果整个 Saga 没有足够快地完成（例如，你想确保你可以仍然撤消操作）