Ibm mq JMSDeliveryMode和消息持久性

这是本报告继续讨论的问题

---

中提到的JMSDeliveryMode是否确定MQ消息是否持久化？

是，只要消息使用IBM的JMS类放在那里。这些类将

JMSDeliveryMode

值转换为一个webspheremq持久性值

C程序可能会尝试设置或更改消息属性，使其与消息头不同，我不确定WMQ API是否会在这种情况下强制实现一致性

但是，重申第一部分，答案是肯定的。链接的页面描述了JMS属性如何映射到本机WMQ头，并且

JMSDeliveryMode

确实映射到

MQMD.Persistence

我注意到您指向V6.0信息中心的链接。希望您还没有使用WMQV6.0，因为它将在几天后停止服务。相同信息的当前信息中心主题是，您会发现它被重新组织并澄清了一些要点。我强烈建议至少迁移到V7.1客户机和QMgr，最好是V7.5，当然还有相应的信息中心

更新：
针对这些意见，优先顺序如下：

如果在所述的托管对象定义中显式设置了持久性，则它优先

如果托管对象设置为

PERSISTENCE=APP

（默认值），则应用程序的设置优先

如果托管对象和应用程序都没有显式设置持久性，那么默认设置是查看队列上的设置并使用该设置

请注意，如果第一次放入消息的队列恰好是一个传输队列，则持久性将在该点确定，并在消息到达的任何位置随消息一起移动，即使远程目标队列设置为

DEFPSIST（NO）

如果仔细查看第一个项目符号中链接的页面，您将注意到一个可能的持久性值HIGH。这一价值的描述似乎已经从书中消失了（我会报告这一点），但它仍然存在。这是JMS的“尽力而为”交付模式，介于WMQ的持续模式和非持续模式之间。由于没有本机等价物，WMQ通过在标记为恢复的队列上使用非持久性消息来实现这一点。当QMgr启动时，将保存队列上的所有非持久性消息，前提是关闭和启动正常，并且队列文件未损坏。即使在具有线性日志记录的QMgr上，也不会记录这些消息以进行介质恢复，因此它们只有一个副本。因此，在大多数情况下，这些消息在重新启动后仍然有效，但如果存在QMgr可以通过删除它们来解决的任何情况，则它们将继续存在

---

请注意页面上的警告，即消息通过的所有队列必须设置为

NPMCLASS（HIGH）

，才能正常工作。如果消息在通过网络的途中以

NPMSPEED（NORMAL）

的方式落在队列上，我不确定消息会发生什么情况，但您可能应该将它们视为非持久消息。

谢谢Rob。至于版本，不，我们使用v7.1。我们将很快进入v7.5：）这是JMSDeliveryMode的默认值吗？发送消息的客户端未设置该值。因此，即使队列DEFPSIST为否，消息也将在QMgr重新启动后继续存在？请参阅更新的答案。谢谢你的投票！接近10公里的目标。：-）