MDB 和欺骗消息答案

【问题标题】：MDBs and dupe messagesMDB 和欺骗消息
【发布时间】：2011-08-01 21:17:04
【问题描述】：

让我们假设 MDB 已收到一条消息并已开始在 CMT/必需事务中处理它，并假设该事务可能需要一些时间才能完成。

在这种情况下，是否有可能在另一个事务中的另一个 MDB 实例接收和处理重复的消息，而第一个事务仍在进行中？

或者容器是否会确保当 MDB 忙于处理 CMT/必需事务中的消息时，没有其他 MDB 实例会收到相同消息的副本？

【问题讨论】：

标签： jakarta-ee ejb message-driven-bean

【解决方案1】：

我希望任何消息在事务的一部分时都被锁定，并且不应该发送重复的消息，因为 JMS 规范要求：

4.4.15 消息的重复生成： JMS 提供者绝不能产生重复的消息。这意味着一个生成消息的客户端可以依赖其 JMS 提供者来确保消息的消费者只会收到一次。

所以我认为您可以依靠消息传递提供程序来确保 MDB 不会收到消息的第二个副本，除非第一个副本显式回滚或事务超时并隐式回滚。这两个操作都应该“解锁”消息并使其可用于重新传递到 MDB，其中 JMSRedelivered 设置为 true 并且 JMSXDeliveryCount 递增。

我怀疑在 EJB、JCA 或 JTA 规范（或 J2EE，就此而言）中的一个（或多个）中补充 JMS 规范有更多要求，我没有检查。

【讨论】：

4.4.15 Duplicate Production of Messages: JMS providers must never produce duplicate messages. This means that a client that produces a message can rely on its JMS provider to insure the consumers of the message will only receive it once. 这是关于AUTO_ACKNOWLEDGE 还是一般情况？因为在DUPS_OK_ACKNOWLEDGE 我认为JMS 提供者可以发送骗子。在 MDB 中，所有确认模式都被忽略。这就是为什么我有点困惑。
一般。 4.4.15 仅适用于一个工作单元的范围内；在事务回滚的情况下，消息肯定有可能多次传递到 MDB。但在交易被撤销之前，您只会得到一份副本。至于 DUPS_OK，它向提供者表明它可以进行延迟确认，如果发生崩溃，则可能不会记录确认，并且可能会在重新启动后重新传递消息。通过设置 DUPS_OK 客户说它不介意以这种方式重复。但这不适用于 XA/MDB 案例。
4.4.15 指的是消息的生产，而不是交付。在 4.4.14 中提到，在自动确认模式下，最后消费的消息可能会被重新传递。
在 XA 下（即 Required）确认模式被忽略，但 4.4.15 相关 - 提供者不得发送另一个在交易进行中复制。因此，回到您最初的问题，不可能“在另一个事务中由另一个 MDB 实例接收和处理重复的消息，而第一个事务仍在进行中”，因为提供者不得这样做。如果第一笔交易失败，消息将被重新传递。请注意有关事务完整性与 AUTO_ACK 的 JMS 规范 cmet - 它们不一样。
我认为 4.4.15 是在讨论生产者/发布者生成和发送消息，而不是消费者/订阅者接收它们。