确认模式

确保可靠传送 JMS 消息的一种机制是，客户端确认使用了由 Message Queue 代理传送给它的消息。

如果在客户端尚未确认消息之前就关闭了会话，或者如果代理在处理确认之前发生了故障，代理将重新传送该消息，并设置一个 JMSRedelivered 标志。

对于非事务会话，客户端可以选择三种确认模式之一，这三种模式有其各自的性能特性：

• AUTO_ACKNOWLEDGE。使用方处理消息后，系统会自动确认该消息。此模式可确保在提供者发生故障后至少重新传送一次消息。

• CLIENT_ACKNOWLEDGE。应用程序控制确认消息的时间点。该会话中自上次确认以来处理的所有消息都将被确认。如果代理在处理一组确认时发生故障，则该组中的一个或多个消息将被重新传送。

• DUPS_OK_ACKNOWLEDGE。此模式指示系统以一种惰性方式确认消息。在提供者发生故障后，可以重新传送多条消息。

（CLIENT_ACKNOWLEDGE 模式的用法与事务的用法类似，不同之处在于：它不能保证当提供者在处理过程中发生故障时，所有确认都将一起处理。）

确认模式影响性能的原因如下：

• AUTO_ACKNOWLEDGE 和 CLIENT_ACKNOWLEDGE 模式需要在代理与客户端之间有额外的控制消息。额外的控制消息会带来额外的处理开销，并干扰 JMS 有效负荷消息，从而导致处理延迟。

• 在 AUTO_ACKNOWLEDGE 和 CLIENT_ACKNOWLEDGE 模式中，客户端必须等到代理确认它已处理客户端的确认后，才能使用其他消息。（这种代理确认可确保代理不会无意地重新传送这些消息。）

• Message Queue 持久性存储库必须用使用方收到的所有持久性消息的确认信息进行更新，因而降低了性能。