《JMS简明教程(PDF格式)》第18章

话输入消息流的顺序依赖于时间。不在应用的控制之下。
4。4。10。2 消息发送的顺序
尽管客户端松散地查看在会话中生产的消息，这些消息形成了一个有序的发送消息流，　
对流进行整体排序是没有意义的。对接收客户端唯一可见的排序是会话发送到一个特定目的　
地的消息的顺序。有几个事情可以影响整个顺序：
z 高优先级的消息可以跳到低优先级消息的前面。
z 客户端可以不接收NON_PERSISTENT　的消息，因为JMS　提供商失败造成。
z 如果　PERSISTENT　和　NON_PERSISTENT　消息被发送到一个目的地，那么只在转发模　
式中保证顺序。也就是说，稍晚的NON_PERSISTENT　消息可以在稍早的PERSISTENT　
之间到达；但是不会在稍早的同优先级的NON_PERSISTENT　消息之前到达。
z 客户端使用事务性的会话将会话发送的消息分组到原子单元（一个　JMS 事务的生　
产者组件）。发送到特定目的地的消息的事务顺序是有意义的。跨目的地发送的消　
息的顺序是没有意义的。参见4。4。7 “事务”了解更详细的信息。
4。4。11　消息确认
如果会话是事务性的，那么消息确认自动由mit　处理，且恢复自动由rollback　处理。
如果会话不是事务性的，有三个确认选择，且手工处理恢复：
z DUPS_OK_ACKNOWLEDGE——这个选项告诉会话懒惰确认消息的传递。如果　JMS　
失败，这很可能造成传递重复消息，因此这个选项只用于可以忍受重复消息的消费　
者。它的好处是减少了会话为防止重复所要做的工作。
z AUTO_　ACKNOWLEDGE——使用这个选项，当消息被成功地从调用接收返回或处理　
消息的MessageListener　成功返回时，会话自动确认客户端的消息接收。
z CLIENT_　ACKNOWLEDGE——使用这个选项，客户端通过调用消息的acknowledge　方　
法来确认消息。确认一个被消费的消息会自动确认被该会话转发的所有消息。
当使用CLIENT_　ACKNOWLEDGE　模式时，客户端可以在处理它们时产生大量未确认消息。　
JMS　提供商应当为管理员提供限制客户端超量运行的途径，以便客户端不会造成资源耗尽并　
保证当它们使用的资源被临时阻塞时造成失败。
会话的recover　方法用于停止一个会话然后使用第一个未确认消息来重新启动它。事实　
上，会话的被转发消息序列被重新设置到最后一个确认消息之后。现在转发的消息序列可以　
与起初转发的消息序列不同，因为消息到期和收到更高优先级的消息。
会话必须设置消息的redelivered　标记，表示它是由于恢复而被重新转发的。
38　/　66
…………………………………………………………Page　39……………………………………………………………
4。4。12　消息的重复转发
JMS　提供商不能重复转发已确认消息。
当客户端使用AUTO_ACKNOWLEDGE　模式时，它不会直接控制消息的确认。由于这种客　
户端不能确切知道某个消息是否已经被确认，因此它们必须做好再次收到最后消费的消息的　
准备。这可能由于客户端完成它的工作恰好在防止消息确认发生失败之前引起。只有会话测　
最后消费的消息会遇到这种情况。JMSRedelivered　消息头字段将用于这种情况下被重发的消　
息。
4。4。13　消息的重复产生
JMS　提供商不能生产重复的消息。这意味着生产消息的客户端可以依赖JMS　提供商来保　
证消息的消费者一个消息只会接收一次。客户端的错误不会引起提供商重复一个消息。
如果在客户端提交和提交方法返回期间出现错误，那么客户端不能决定事务是否被提交　
还是被回滚。当非事务性的发送一个　PERSISTENT　消息和发送方法返回之间产生错误时，会　
产生同样的不确定性问题。
这种不确定性由JMS　应用来处理。在某些情况下，这可能会造成客户端生产重复消息。
由于恢复被重发的消息不认为是重复消息。
4。4。14　客户端代码的有序执行
尽管java　语言本身提供多线程，但写多线程程序仍然比写单线程程序困难。
因此，JMS　不会引起客户端代码的并非执行，除非客户端显式地要求这样做。做到这一　
点的一种途径是一个会话对所有消息的异步转发进行排序。
为了异步接收消息，客户端向MessageConsumer　注册实现了JMS　MessageListener　接口　
的对象。事实上，会话使用一个单线程来运行所有的MessageListener。当线程正在执行一个　
监听器时，所有其他被异步转发的消息必须等待。
4。4。15　并行消息转发
希望并行转发的客户端可以使用多会话。事实上，每个会话的监听器线程并行的运行。　
当会话上的监听器正在执行时，在另一个会话上的监听器也可以被执行。
注意，JMS　本省不提供并行处理主题消息集合的功能（这些消息被转发到单个消费者）。　
客户端可以使用单个消费者但实现多线程逻辑来并行处理这些消息；但是，这样做是不可靠　
的，因为JMS　没有事务功能来处理这种方式需要的并发事务。
4。5 MessageConsumer
客户端使用　MessageConsumer 来接收来自目的地的消息。通过向　Session 的　
createConsumer　方法传入Queue　或Topic　来创建MessageConsumer。
消费者可以用消息选择器来创建。这可以让客户端限制转发到消费者的消息，只有符合　
39　/　66
…………………………………………………………Page　40……………………………………………………………
选择器的消息才能被转发到该消费者。参见节3。8。1 “消息选择器”了解更详细的信息。
客户端可以同步接收消费者的消息，也可以让提供商在消息到达时异步地转发消息。
4。5。1　同步转发
客户端可以要求来自MessageConsumer　的下一个消息使用某个receiver　方法。有几个接　
收变量可以让客户端获取或等待下一个消息。
4。5。2　异步转发
客户端可以向MessageConsumer　注册一个实现了JMS　MessageListener　接口的对象。当　
消息到达消费者时，提供商通过调用监听器的onMessage　方法来转发它们。
监听器可能会抛出RuntimeException；但是这被看作是客户端程序错误。好的监听器应　
当捕获这种异常并尽量将产生异常的消息转发到应用的‘未处理消息’目的地。
监听器抛出RuntimeException　的结果依赖于会话的确认模式。
z AUTO_ACKNOWLEDGE　或DUPS_ACKNOWLEDGE——消息被立即重发。JMS　提供商在　
放弃之前重发同一个消息次数由提供商决定。在这种情况下，将为重发的消息设置　
JMSRedelivered　消息头字段。
z CLIENT_ACKNOWLEDGE——为监听器转发下一个消息。如果客户端希望让前一个未　
确认的消息被重发，那么它必须手工恢复会话。
z 事务性的会话——为监听器转发下一个消息。客户端可以提交或回滚这个会话（换　
句话说，RuntimeException　不自动回滚这个会话）。
JMS　提供商应当对抛出RuntimeException　作为可能故障的具有消息监听器的客户端进行　
标记。
参见节4。4。14 “客户端代码的顺序执行”了解onMessage　如何被会话有序的调用。
4。6 MessageProducer
客户端使用MessageProducer　来向Destination　发送消息。通过向会话的createProducer　
方法传入Queue　或Topic　来创建Me