消息接收确认
JMS消息只有在被确认之后,才认为已经被成功地消费了
消息的成功消费通常包含三个阶段:
客户接收消息、客户处理消息和消息被确认。
在事务性会话中,当一个事务被提交的时候,确认自动发生
在非事务性会话中,消息何时被确认取决于创建会话时的应答模式
非事务消息的确认模式
Session.AUTO_ACKNOWLEDGE:
当客户成功的从receive方法返回的时候,
或者从 MessageListener.onMessage方法成功返回的时候,会话自 动确认客户收到的消息。Session.CLIENT_ACKNOWLEDGE:
客户通过调用消息的acknowledge方法确认消 息
注意:确认一个被消费的消息 将自动确认所有已被会话消费的xiao消息
例如,如果一个消息消费者消费了10 个消 息,然后确认第5 个消息,那么所有10 个 消息都被确认Session.DUPS_ACKNOWLEDGE:
该选择只是会话迟钝的确认消息的提交。如果JMS provider失败,那么可能会导致一些重复的消息
消息提交模式
PERSISTENT:指示JMS provider持久保存消息,以保证消息不会因为JMSprovider的失败而丢失
NON_PERSISTENT:不要求JMS provider持久保存消息
消息的临时目的地
可以通过会话上的createTemporaryQueue 方法和createTemporaryTopic 方法来创建临时目的地。它们的存在时间只限于创建它们的连接所保持的时间。 只有创建该临时目的地的连接上的消息消费者才能够从临时目的地中提取消息
pub/sub持久订阅
首先消息生产者必须使用PERSISTENT提交消息
客户可以通过会话上的createDurableSubscriber方法来创建一个持久订阅.
该方法的第一个参数必须 是一个topic。第二个参数是订阅的名称。
JMS provider会向客户发送客户处于非激活状态时所 发布的消息。
本地事务
在一个JMS客户端,可以使用本地事务来组合消息的发送和接收。JMS
Session接口提供了commit和rollback方法。事务提交意味着生产的所有消息被 发送,消费的所有消息被确认;事务回滚意味着生产的所有消息被销毁,消费的 所有消息被恢复并重新提交,除非它们已经过期。
注意:如果使用请求/回复机制,即发送一个消息,同时希望在同 一个事务中等待接收该消息的回复,那么程序将被挂起,因为直到事务提交,发 送操作才会真正执行。