如果JMS客户端应用程序要求不会丢失任何消息，并且没有发送重复项进行处理，并且每条消息与其他消息无关（无批处理），则哪种组合满足以下要求： - 持久性+自动确认会话模式（异步消费者） - 持久性+客户端确认会话模式 - 持久性+交易会话 - 任何其他？ 我已经阅读过有关交易会话和交易模式的信息（例如http://docs.oracle.com/javaee/1.4/tutorial/doc/JMS6.html和http://wso2.com/library/articles/2013/01/jms-message-delivery-reliability-acknowledgement-patterns/），在我看来，这三种可能性都是可以接受的。你同意吗？使用事务处理会话或更高级的可靠性概念会有什么好处？
提前致谢！
答案 0 :(得分：3)
如果您通过网络与任何JMS传输提供商交谈，请使用事务处理会话并确保该应用检测并正常处理欺诈消息。为什么？请查看 4.4.13重复制作邮件部分中的JMS 1.1 specification，其中说明：
如果客户端在a上工作时发生故障 Session和commit方法返回，客户端无法确定是否 事务已提交或回滚。同样含糊不清 当非事务性发送a之间发生故障时存在 PERSISTENT消息和发送方法的返回。
由JMS应用程序来处理这种歧义。在一些 这种情况，这可能会导致客户产生功能上的重复 消息。
由于会话恢复而重新传递的消息不是 被视为重复的消息。
考虑通过网络发布COMMIT的应用程序。如果应用收到指示连接已断开的错误，它是如何知道API调用到达传输提供商之前或之后发生的？如果应用程序正在发送消息，唯一安全的做法是假设COMMIT失败并重新发送消息。收到消息的东西会再次看到它。
同样，如果实际上已回滚，则接收在COMMIT上收到错误消息的应用会再次看到该消息。但是，应用程序不能假设它已回滚并丢弃它刚收到的消息，因为这可能会导致消息丢失。
因此，WMQ或任何其他JMS传输提供商不得提供欺骗，但由于网络引入的歧义，应用程序可能会收到欺诈。这是假设事务会话和应用程序优雅地处理欺骗的最佳情况。最糟糕的情况是，在交易会话之外，歧义可能导致应用程序丢弃消息。