背景
我有一个 Spring 客户端应用程序，它使用 RMI 为两个服务器提供服务。在客户端中，我将一个实体保存到数据库中(简单)，并使用实体的详细信息对两个服务器进行 rmi 调用。我在服务器上使用 Spring 3.0.2，客户端是一个简单的 Spring-mvc 站点。
要求
我的要求是，如果对服务器的任何 rmi 调用失败，整个事务将回滚，即实体不会保存在客户端上，如果任何一个 rmi 调用成功，这也会回滚。
我对分布式事务比较陌生，但我想我想要一个使用 RMI 调用的类似 XA 的事务。
我确实找到了关于这个主题的一个很好的链接 here但它没有提到对不同服务器调用两个远程方法调用时的模式。我很想在推荐阅读方面听到更多关于这个主题的信息，以及关于如何使用 spring 实现这一点的任何指示。为此可能使用事务管理器吗？
谢谢。
最佳答案
这是理论上如何处理这种情况的方法。首先你需要在每个节点上有几个 JTA 分布式事务管理器。一个充当主人，另一个充当奴隶。 master 协调分布式事务到 slaves 的提交/回滚。存在独立的 JTA 实现，例如JOTM .
Vanilla RMI 不支持传播上下文信息，例如操作的事务 ID。但我认为 RMI 有钩子(Hook)，因此它可以扩展以支持它。你可以看看Carol .
您将需要使用 XAResource将参与者包装在事务中，以便他们可以参与分布式事务。 master 需要向 slaves 发送提交/回滚消息，这需要使用 XATerminator采取相应行动。
JTA 规范只是一个分布式事务管理器，事务日志中的操作记录需要由服务器来完成。存在用于事务日志管理的库，例如HOWL .
我不认为可以使用 Spring —— 即使使用分布式事务管理器 —— 来轻松地做到这一点。我试过一次使用 RMI 和分布式事务控制从一个独立的客户端和几个奴隶。这是一个 blog post关于它。这相当复杂。
如果您使用带有 IIOP 的 Java EE 应用程序服务器，则可以免费获得所有这些。 IIOP 支持分布式事务传播。客户端可以是 application client container ，您可以使用 UserTransaction 控制交易.这实际上是一种罕见的情况，我认为在这种情况下使用应用服务器确实是合理的。
不过话说回来，分布式事务是个复杂的东西，会导致启发式失败，一个节点挂掉就会超时，恢复过程也很复杂。
我最后的建议是:如果可能的话，尽量找一个不涉及分布式事务的设计。这会让你喜欢的更容易。
您或许可以从 BPEL 中汲取灵感 compensation mechanism .可能还有其他用于错误处理和稳健性的设计方法可以避免使用分布式事务。
关于java - Spring分布式事务涉及RMI调用可能吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3148090/