【JMS】消息确认机制

参考：

https://www.cnblogs.com/resentment/p/5761118.html

https://www.cnblogs.com/chenying99/p/3164640.html

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q032230_.htm

消息的确认是指消息接受者接到消息,并做出了对应的处理之后,它将回送一个确认消息。

在JMS规范中一共4种确认方式
AUTO_ACKNOWLEDGE当调用recieve方法成功后或MessageListener处理函数成功返回后进行确认
CLIENT_ACKNOWLEDGE客户端通过message的acknowledge方法手动确认
DUPS_OK_ACKNOWLEDGE延迟确认，在对重复接受同一消息不敏感时可以选用此确认模式，相比AUTO_ACKNOWLEDGE有性能提升
SESSION_TRANSACTED调用session的commit或rollback进行事务式确认

创建Session时调用了Connection的方法,第一个false参数，是表明会话是否具有事务性；如果是false，必须指定确认方式。

对于非事务性会话,创建会话时应该指定确定方式,JMS定义了3种确认方式:

JMS确认3种方式
Auto_ACKnowledge	自动通知. 对于同步消费者,Receive方法调用返回,且没有异常发生时,将自动对收到的消息予以确认. 对于异步消息,当onMessage方法返回,且没有异常发生时,即对收到的消息自动确认. 如果消息接收方的确认返回失效，则此消息被允许再次发送，要求消息接收方可以允许或者处理被重复发送并接收的消息。
Client_AcKnowledge	客户端自行决定通知时机 这种方式要求客户端使用javax.jms.Message.acknowledge()方法完成确认.
Dups_OK_ACKnowledge	延时//批量通知 这种确认方式允许JMS不必急于确认收到的消息,允许在收到多个消息之后一次完成确认,与Auto_AcKnowledge相比,这种确认方式在某些情况下可能更有效； 但若遇到确认失效,比如当系统崩溃或者网络出现故障的时候,多个消息会被重新传递。

 注意一个限制：

AUTO 和 DUPS_OK 模式下，JMS 只能处理消息被ACK的情况，而无法处理 MessageListener抛出异常的情况。

因此如果需要对消息确认的全面控制，建议只用CLIENT模式，可以处理复杂的消息异常。