按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
们的生命周期与连接相同，连接的所有会话都可以创建临时目的地的MessageConsumer。
临时目的地（TemporaryQueue 或TemporaryTopic 对象）是系统为连接生成的唯一的目
的地。只有它们自己的连接才可以为它们创建MessageConsumer。
临时目的地的通常用法师作为JMSReplyTo 的目的地。
每个TemporaryQueue 或TemporaryTopic 对象都是唯一的。不能够被复制。
由于临时目的地可以分配JVM 外部的资源，如果这些资源不再使用，应当及时删除它
们。当它们被垃圾回收或连接关闭时，这些资源将被自动删除。
4。4。4 创建目的地对象
大多数的客户端都将使用Destination，Destination 是JMS 的受管理对象，通过JNDI 查
35 / 66
…………………………………………………………Page 36……………………………………………………………
找它们。这是最方便的方法。
某些特殊的客户端可能需要动态操纵使用提供商特有的目的地名来创建Destination。会
话为JMS 提供商提供了实现这个功能的提供商专用的方法。
4。4。5 优化消息实现
会话提供使用提供商优化过的实现来创建消息的方法。这可以让提供商最小化处理消息
的负荷。
会话必须能够发生所有的JMS 消息而不管它们如何被实现的。
4。4。6 使用会话的约定
会话被设计成一个时间只能由一个线程使用。一个例外情况是在会话或它的连接依次关
闭时可以多个线程使用。参见节4。3。5 “关闭连接”和节4。4。1 “关闭会话”了解更详细的信
息。
一个典型的用法是让一个线程阻塞在同步的 MessageConsumer 上，直到有消息到达。
这个线程然后使用一个或多个MessageProducer。
如果已经有一个客户端控制线程正在这个会话中等待接收消息，那么另一个客户端控制
线程不能同步接收消息。
另一个典型的用法是让一个线程通过创建会话的生产者和一到多个异步消费者来设置
会话。在这种情况下，消息生产者不能独占消费者消息监听器。由于会话按顺序执行消费者
的MessageListener，因此这些监听器可以安全地共享会话的资源。
如果在会话正在被设置时连接处于停止模式，那么客户端在完全准备好处理消息之前不
需要处理到达的消息。这是最好的策略，因为它降低了设置和消息处理间出现冲突的可能性。
当连接正在接收消息时可以创建和设置会话。在这种情况下，要注意保证会话的
MessageProducer、MessageConsumer 和MessageListener 要按正确的顺序创建。例如，错误
的顺序可能引起 MessageListener 使用还没有创建号的 MessageProducer ；或由于
MessageListener 注册的顺序不正确而使得消息按错误的顺序到达。
如果客户端希望在其他线程消费消息时有一个线程产生消息，那么客户端应当为生产消
息的线程使用独立的会话。
一旦连接被启动，则它的所有带有消息监听器的会话都致力于给它们转发消息的控制线
程。从另外一个控制线程中使用这些会话的客户端代码是错误的。唯一的例外是这种非那个
是可以用于会话或连接的关闭方法。
对会话增加单线程控制的限制的结果是带消息监听器的会话也不能同步接收消息。会话
要么致力于用作转发消息到消息监听器的控制线程，要么致力于由客户端初始化的控制线程。
不能在同一个会话中同时使用。
另一个结果是，连接必须在停止模式下对带多个消息监听器的会话进行设置。原因是当
连接正在转发消息，一旦第一个消息监听器被注册，则会话就由向这个监听器转发消息的控
制线程控制。此时，客户端的控制线程不能进一步配置这个会话。
对大多数客户端来说，将它们的工作分派到多个会话是很正常的。这个模型可以让客户
端简单的启动和随着并发增长的需要而逐渐地增加消息处理。
36 / 66
…………………………………………………………Page 37……………………………………………………………
4。4。7 事务
Session 可选地可以被指定为事务性的。每个事务性的会话支持单序列的事务。每个事
务将一系列生成的消息和一系列消费的消息分组到一个原子工作单元。效果是，事务将会话
的输入消息流和输出消息流组织称一系列的原子单元。当事务提交时，输入原子单元被确认，
输出原子单元被发送。如果事务回滚，则它生产的消息被销毁，它消费的消息被自动恢复。
关于会话恢复的详细信息，参见节4。4。11 “消息确认”。
会话使用它的mit（）或rollback（）方法来完成会话。当前事务完成时会自动启动下一个
事务。因此，事务性的会话当前总会有一个事务。
JTS 或一些其他的事务监控器工具可以被用于将会话的事务和其它资源（数据库，其他
的JMS 会话等等）上的事务组合在一起。由于Java 分布式事务由JTA 事务分割API 控制，因
此在这种上下文中使用会话的 mit 和 rollback 方法将抛出 JMS 的
TransactionInProgressException 。
4。4。8 分布式事务
JMS 不要求提供商支持分布式事务；但是如果提供商支持了，则应当通过JTA XAResource
API 来提供分布式事务。
JMS 提供商也可以是分布式事务监听器。如果它是，那么它应当通过JTA API 提供事务
控制。
尽管对JMS 客户端来说它可以直接处理分布式事务，但JMS 客户端尽量不要这样做。
使用基于XA 接口的JMS 客户端在第8 章“JMS 应用服务器工具”中描述，但这种客户端不
能跨不同的JMS 实现进行移植，因为这些接口是可选的。在JMS 中支持JTA 是为了系统提
供商能够将JMS 集成到他们的应用服务器产品中。参见第8 章“JMS 应用服务器工具”了解
更详细的信息。
4。4。9 多会话
一个客户端可以创建多个会话。每个会话都是一个独立的消息生产者和消费者。
对于Pub/Sub，如果两个回合都有一个TopicSubscriber ，且都订阅同一个Topic ，那么每
个订阅者都会收到消息。它们之间不会相互阻塞。
对于PTP，JMS 没有指定对同一个Queue 并发QueueReceiver 的语义。但是，JMS 没有
禁止提供商提供这个功能。因此，向多个QueueReceiver 转发消息将依赖JMS 提供商的实现。
但这是不可移植的。
4。4。10 消息排序
JMS 客户端不需要理解它们什么时候可以依靠消息排序，什么时候不能。
37 / 66
…………………………………………………………Page 38……………………………………………………………
4。4。10。1 消息接收的顺序
由会话消费的消息定义了一系列的顺序。这个顺序是重要的，因为它定义了消息确认的
顺序。参见4。4。11 “消息确认”了解详细信息。每个会话消费者交叉读取会话输入消息流中
的消息。
JMS 定义了由会话发送到目的地的消息必须按它们发送的顺序被接收（参见节4。4。10。2
“消息发送的顺序”了解限制条件）。这节定义了一部分在会话输入消息流上排序的约束。
JMS 没有定义跨目的地接收消息的顺序或从多个会话发送的跨目的地的消息的顺序。会
话输入消息流的顺序依赖于时间。不在应用的控制之下。
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 标记，表示它是由于恢复而被重新转发的。