JMS 本地事务与事务管理器答案

【问题标题】：JMS Local transactions vs TransactionManagerJMS 本地事务与事务管理器
【发布时间】：2016-05-17 05:45:24
【问题描述】：

我最近一直在研究 Jms API，但我不确定我是否了解本地与事务管理器的区别。

场景 1：

使用来自 Jms 代理的消息，处理消息并在处理成功后提交事务，否则回滚。

场景 2：

我想将消息从一个代理代理到另一个代理，但我不想使用 XA 事务，因为它的速度很慢。所以这个想法是为我正在消费的代理启动一个事务，然后在该事务中为我正在生产的代理启动第二个事务，然后连续提交这两个事务。让我们忽略这种情况下可以缓解的重复风险问题

使用 JMS commit()、rollback() API（也称为本地事务）与使用事务管理器（例如 Spring 的 PlatformTransactionManager 类）之间到底有什么区别？在第二种情况下是否需要事务管理器，为什么需要/不需要？

【问题讨论】：

正如你所说的XA transactions are slow due its nature，我想知道你的陈述是从哪里得到的吗？
根据我自己比较非 XA 与 XA 交易的经验。通过阅读 XA 事务必须做多少工作才能保持 N 资源同步，我认为这是导致性能差异的原因
感谢您的反应。我的兴趣来自您的第二种情况，因为我的印象是您想在没有 XA 的情况下模拟 XA 事务。这是否意味着您不想使用资源锁定？
我的意思是你不介意邮件丢失在箱子里吗？就像您阅读消息时出现的问题，提交 txn 接收消息并且您的应用程序崩溃。然后在此过程中忘记了此类消息。还是我在这里错了？ XA 事务确实有其开销，但另一方面它能够在崩溃后恢复系统。
不会发生任何损失，但可以复制。您从 txn 1 上的代理 1 读取并在 txn 2 上发送到代理 2，然后提交 txn 2，然后在 txn 1 上提交。如果应用程序在 2 次提交之间崩溃，您会在双方收到相同的消息，从而导致潜在的重复。

【解决方案1】：

事务管理器将确保跨服务器的事务要么一起提交，要么一起回滚。

手动管理单独的事务会带来漏洞，例如服务器 A 事务已提交，但服务器 B 不能，因为存在任何数量的错误条件（网络、应用程序故障等）。在很多情况下，事务管理器可以缓解这些问题。

可能是您的应用程序是幂等的并且可以处理多次看到相同的消息并正确处理它，或者存在可以纠正不良情况的流程问题，在这种情况下您可能没问题。

【讨论】：