Issue Details (XML | Word | Printable)

Key: JMS_SPEC-52
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Nigel Deakin
Reporter: Nigel Deakin
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
jms-spec

Clarify that a message may be sent using a different session from that used to create the message

Created: 21/Sep/11 11:37 AM   Updated: 21/Sep/12 02:04 PM   Resolved: 21/Sep/12 02:04 PM
Component/s: None
Affects Version/s: 1.1
Fix Version/s: 2.0ED, 2.0

Time Tracking:
Not Specified

Issue Links:
Dependency
 

Tags: ed20-added
Participants: Nigel Deakin


 Description  « Hide

The JMS 1.1 API defines how a JMS message object is created using one of the following methods on a Session:

Message 	createMessage() 
BytesMessage 	createBytesMessage() 
MapMessage 	createMapMessage() 
ObjectMessage 	createObjectMessage() 
ObjectMessage 	createObjectMessage(java.io.Serializable object) 
StreamMessage 	createStreamMessage() 
TextMessage 	createTextMessage() 
TextMessage 	createTextMessage(java.lang.String text) 

The following question has been raised:

Can a message be sent using a MessageProducer that was created from a different Session than was used to create the message?

This is not stated explicitly in the specification, and discussions within the JSR 343 Expert group show that different individuals have come to different conclusions on this issue.

My own interpretation is that a MessageProducer must be able to send a javax.JMS.Message irrespective of how it was created. It might have been created using Session.createMessage(), or it may have been received by a MessageConsumer.

Section 4.4.5 "Optimized message implementations" of the JMS 1.1 specification states:

A session provides message create methods that use provider-optimized implementations. This allows a provider to minimize its overhead for handling messages.
Sessions must be capable of sending all JMS messages regardless of how they may be implemented.

Furthermore, Section 3.12 of the JMS 1.1 specification states explicitly that a MessageProducer must be able to send a message that was created using a different JMS provider, and which would therefore have used a different session:

A provider must be prepared to accept, from a client, a message whose implementation is not one of its own. A message with a 'foreign' implementation may not be handled as efficiently as a provider's own implementation; however, it must be handled.

Despite this, there is a widespread view within the JMS community that for messages created within the same JVM by the same JMS provider, the session used to create the message must be the same as that used to send it.

It is therefore proposed that the JMS specification be clarified that there is no such restriction, and that a MessageProducer can be used to send any message object

  • irrespective of which session or connection was used to create it,
  • irrespective of whether the message was created within this JVM or received from a JMS destination, and
  • irrespective of whether the MessageProducer and message are implemented by the same or different JMS providers.


Nigel Deakin added a comment - 22/Sep/11 11:13 AM

Edited description to clarify that a MessageProducer can be used to send any message object
irrespective of what connection (as well as session) was used to create it.


Nigel Deakin added a comment - 19/Dec/11 05:26 PM - edited

I've now updated the javadocs and the draft spec to clarify this issue (these changes are additive, so those docs include other changes).

The updated Javadocs are here:
http://java.net/projects/jms-spec/sources/repository/content/jms2.0/target/jms-2.0-javadoc.jar

The six message-creation methods on Session have been modified to include the following additional javadoc comments:

* The message object returned may be sent using any session or messaging context. 
* It is not restricted to being sent using the session used to create it.
* <p>
* The message object returned may be optimised for use with the JMS provider
* used to create it. However it can be sent using any JMS provider, not just the 
* JMS provider used to create it.

The second sentence above has been included because it would be confusing and inconsistent to mention that a message may be sent using a different session and not also mention the even more significant fact that a message may be sent using a different JMS provider.

The six message-creation methods on the proposed new MessagingContext interface have been modified to include the following additional javadoc comments:

* The message object returned may be sent using any session or messaging context. 
* It is not restricted to being sent using the messaging context used to create it.
* <p>
* The message object returned may be optimised for use with the JMS provider
* used to create it. However it can be sent using any JMS provider, not just the 
* JMS provider used to create it.

The updated draft spec is here:
http://java.net/projects/jms-spec/sources/repository/content/jms2.0/specification/word/JMS20.pdf
All changes are highlighted clearly with changebars. The changes for this issue are as follows:

Section 4.4.5. "Optimized Message Implementations" has been updated to state:

A session provides the following methods to create messages: createMessage, createBytesMessage, createMapMessage, createObjectMessage, createStreamMessage and createTextMessage.

These methods allow the JMS provider to create message implementations which are optimized for that particular provider and allow the provider to minimize its overhead for handling messages.

A session provides message create methods that use provider-optimized implementations. This allows a provider to minimize its overhead for handling messagesHowever .the fact that these methods are provided on a session does not mean that messages must be sent using a message producer created from the same session. Messages may be sent using any session, not just the session used to create the message.

Furthermore, Sessions must be capable of sending all JMS messages regardless of how they may be implemented. See section 3.12 "Provider Implementations of JMS Message Interfaces".

Section 11.5.5 "Clarification: message may be sent using any session" is the change log for this clarification.