JMS理应要求所有对象都支持并发使用。考虑到对并发访问的支持会增加一些成本和复杂性,JMS的设计仅要求那些自然而然地被多线程客户端访问的对象要支持并发。其他对象被设计成在同一时间内只能被一个逻辑线程访问。
表2-2 在传统API中使用的对象哪些支持并发
| JMS对象 | 是否支持并发 | 
|---|---|
| Destination | 是 | 
| ConnectionFactory | 是 | 
| Connection | 是 | 
| Session | 否 | 
| MessageProducer | 否 | 
| MessageConsumer | 否 | 
表2-3 在简化API中使用的对象哪些支持并发
| JMS对象 | 是否支持并发 | 
|---|---|
| Destination | 是 | 
| ConnectionFactory | 是 | 
| JMSContext | 否 | 
| JMSProducer | 否 | 
| JMSConsumer | 否 | 
表2-4 在点对点域特定API中使用的对象哪些支持并发
| JMS对象 | 是否支持并发 | 
|---|---|
| Destination | 是 | 
| QueueConnectionFactory | 是 | 
| QueueConnection | 是 | 
| QueueSession | 否 | 
| QueueSender | 否 | 
| QueueReceiver | 否 | 
表2-5 在发布订阅域特定API中使用的对象哪些支持并发
| JMS对象 | 是否支持并发 | 
|---|---|
| Destination | 是 | 
| TopicConnectionFactory | 是 | 
| TopicConnection | 是 | 
| TopicSession | 否 | 
| TopicPublisher | 否 | 
| TopicSubscriber | 否 | 
JMS定义了一些约束会话并发使用的特定规则。这些规则用于传统API的Session对象和域特定API中的QueueSession和TopicSession对象。它们也用于简化API中的JMSContext对象,因为它包含了一个Session。由于详细解释这些规则所需要的知识超出了这里的内容,我们将在稍后再详细阐述,这里仅仅说明一下引入它们的依据。
有两个理由需要约束会话的并发访问。第一,会话是支持事务的实体,但是实现多线程的事务是非常困难的。第二,会话支持异步消息消费。一个很重要的事情是,JMS不要求异步消费的客户端代码有能力处理多个并发消息。此外,如果一个会话上创建了多个异步消费者,那么客户端不必处理每个单独消费者当前执行的情况也非常重要。这些约束对典型的客户端来说,使得JMS更容易使用。更复杂的客户端可以使用多个会话来支持自己需要的并发场景。在传统API或域特定API里,这意味着需要多个Session对象。在简化API里,这意味着需要多个JMXContext对象。