JMS简明教程(PDF格式)-第10部分
按键盘上方向键 ← 或 → 可快速上下翻页,按键盘上的 Enter 键可回到本书目录页,按键盘上方向键 ↑ 可回到本页顶部!
————未阅读完?加入书签已便下次继续阅读!
如果stop 方法被调用时消息监听器(MessageListener)仍在运行,则必须在所有的监听器
都返回后才能停止。当这些消息监听器将要完成时,他们必须拥有连接的所有服务。
4。3。5 关闭Connection
由于提供商通常为Connection 分配JVM 外部的资源,因此客户端应当在它们不需要的
时候关闭这些资源。依赖垃圾回收来回收这些资源可能不是非常及时。
关闭操作将终止所有连接会话消费者接收的未处理消息。接收可能返回一个消息也可能
返回null,这要根据关闭时刻是否可以获得一个消息。
注意,在这种情况下,如果消息消费者企图用这个关闭的连接来处理最后的消息,它很
可能会得到一个异常。开发者在写消息消费者的时候必须考虑这种“最后的消息”。必须再
次强调,消息消费者不能依靠空返回值来判断“最后的消息”。
如果一个或多个消息监听器在连接关闭被调用时正在处理消息,那么在控制没有返回给
JMS 提供商之前就必须保持连接和会话的所有功能都可以被那些监听器获得。
当连接被关闭时,直到消息处理按顺序都被停止后关闭方法才能返回。这意味着所有正
在运行的消息监听器已经返回且所有未处理的接收已经返回。
如果连接被关闭,不需要关闭它的组成对象。连接关闭足以通知 JMS 提供商应当释放
连接的所有资源。
关闭连接必须回滚处于处理的交易会话中的事务(注:术语“交易会话”指的是会话的
提交和回滚方法用于分割会话的本地事务。在这种情况下会话的工作和外部的事务管理器的
工作是一致的,此时不使用会话的提交和回滚方法,被关闭的会话的工作的结果随后由事务
管理器决定。)。关闭连接不会强迫客户端确认会话的确认。调用来自已关闭的会话的已接收
消息的acknowledge 方法必须抛出IllegalStateException。对于那些要求由JMS 客户端连续可
靠处理的队列和长期订阅来说,这些语义保证关闭连接不会造成消息的丢失。
一旦连接被关闭,企图使用它或它的会话或它们的消息消费者和生产者必须抛出
IllegalStateException (必须忽略对这些对象的close 方法的调用)。但继续使用通过这个连接
创建或接收的消息对象仍是有效的,除了已接收消息的acknowledge 方法。
关闭一个已关闭的连接不必抛出异常。
33 / 66
…………………………………………………………Page 34……………………………………………………………
4。3。6 会话(Session)
Connection 是Session 的工厂,它底层使用对JMS 提供商的连接来生产和消费消息。
4。3。7 ConnectionMetaData
Connection 提供ConnectionMetaData 对象。这个对象提供了提供商支持的JMS 的最新
版本和提供商的产品名和版本。
它也提供了连接支持的JMS 定义的属性名列表。
4。3。8 ExceptionListener
如果JMS 提供商检测到与连接有关的问题,那么它将通知连接的ExceptionListener,如
果它已经被注册。为了取出ExceptionListener,JMS 提供商调用连接的getExceptionListener()
方法。这个方法返回这个连接的ExceptionListener。如果没有注册ExceptionListener,则返回
null 。连接然后可以通过调用监听器的 onException()方法来使用监听器,传入描述问题的
JMSException 。
这可以让客户端异步通知问题。某些连接只消费消息,因此它们没有其他途径来获知它
们的连接已经失败。
连接序列化ExceptionListener 的执行。
JMS 提供商应当在通知客户端之前尽力解决连接问题。
转发到ExceptionListener 的异常是那些没有其他地方可报告的异常。如果在JMS 调用连
接时抛出异常,按照定义不会将这个异常转发给 ExceptionListener (换句话说,
ExceptionListener 不是用于监听由连接抛出的所有异常)。
4。4 Session
JMS Session 是一个单线程的上下文(对能够使用会话对象或它创建的线程的数量没有
限制。限制是会话的资源不应当被多个线程并发使用。这由用户来保证满足这个限制。最简
单的方式是使用一个线程。在异步转发的情况下,使用一个线程来设置停止模式然后启动异
步转发。在更复杂的情况下,用户必须提供显式的同步。),用于生产和消费消息。尽管会话
可以给提供商分配JVM 外部的资源,但是它被看作是轻量JMS 对象。
Seesion 用于几个目的:
z 它是MessageProducer 和MessageConsumer 的工厂。
z 它是TemporaryTopic 和TemporaryQueue 的工厂。
z 它为需要动态操纵提供商专有目的地名字的客户端提供了一种创建Queue 或Topic
对象的途径。
z 它提供了提供商优化后的消息工厂。
z 它支持事务串,这些事务将跨会话生产者和消费者的工作组合成原子单元。
z 它为它消费的消息和它生产的消息定义了一个连续的顺序。
z 它保留它消费的消息直到这些消息被确认。
34 / 66
…………………………………………………………Page 35……………………………………………………………
z 它序列化注册到它的MessageListener 的执行。
z 它是QueueBrowser 的工厂。
4。4。1 关闭会话
由于提供商可以代表会话分配位于JVM 之外的资源,客户端应当在这些资源不需要的
时候关闭它们。依靠垃圾回收来最终回收它们不是非常及时的。对于由会话创建的
MessageProducer 和MessageConsumer 来说同样需要这样做。
关闭会话会中止这个会话上的所有消息处理。它必须处理由会话消费者未处理的接收或
正在运行的消息监听器的关闭,正如在节4。3。5 “关闭连接”中所述。
关闭会话的方法可以从一个不同于当前控制这个会话的控制线程调用。
当会话关闭被调用时,在消息处理被按顺序停止前关闭方法不能返回。这意味着不会有
消息监听器正在运行,且如果有未处理的接收,则它返回null 或者一个消息。
当会话被关闭时,不需要关闭它的消息生产者和消费者。会话关闭足够通知 JMS 提供
商释放会话的所有资源。
关闭有事务的会话必须回滚处理中的事务。关闭客户端确认的会话不强迫确认。
一旦会话被关闭,那么企图使用它或它的消费者和生产者必须跑出IllegalStateException
(必须忽略对这些对象close 方法的调用)。继续使用通过这个会话创建或接收的消息对象
是有效的,除了已接收消息的acknoledge 方法。
关闭一个已关闭的会话不能抛出异常。
4。4。2 创建MessageProducer 和MessageConsumer
会话可以创建和服务于多个 MessageProducer 和 MessageConsumer 。参见节 4。5
“MessageConsumer”和节4。6 “MessageProducer”了解创建和使用它们的详细信息。
尽管会话可以创建多个生产者和消费者,它们必须依次使用。在效果上,只有一个逻辑
控制线程可以使用它们。这在后面会详细的解释。
4。4。3 创建临时目的地
尽管会话被用于创建临时目的地,这只是为了方便。它们的范围实际上是整个连接。它
们的生命周期与连接相同,连接的所有会话都可以创建临时目的地的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 控制,因
此在这种上下文中使用