CODEWITHSUNDEEP
javajmsactivemq-classic
pjj
pjj

Reputation: 2135

JMS 2.0 specs - how a JMS provider can detect the change in Message object by a JMS client?

I was reading JMS 2.0 specs and it is mentioned that (below relevant excerpt) if client tries modify the Message object then JMS provider may throw an exception.

My question is how a JMS provider would know if client is trying to modify the Message object, because Message object would be transmitted over the wire and at JMS provider end it is not the same heap object so even if client modifies that Message object, JMS provider has no way to detect the change.

Am I missing something?

7.3.9. Restrictions on the use of the Message object

Applications which perform an asynchronous send must take account of the restriction that a Message object is designed to be accessed by one logical thread of control at a time and does not support concurrent use. See section 2.14 “Multi-threading”.

After the send method has returned, the application must not attempt to read the headers, properties or body of the Message object until the CompletionListener’s onCompletion or onException method has been called. This is because the JMS provider may be modifying the Message object in another thread during this time.

A JMS provider may throw a JMSException if the application attempts to access or modify the Message object after the send method has returned and before the CompletionListener has been invoked. If the JMS provider does not throw an exception then the behaviour is undefined.

Upvotes: 1

Views: 139

Answers (2)

Axel Podehl
Axel Podehl

Reputation: 4303

This text is referrent to your provider's implementation of the JMS Message object. When received from the JMS consumer, this message usually has a read-only flag turned on, also to make improved performance possible, that will be checked in the implementation of 'Message' when you use methods that would modify the message. For example TextMessage.setText() would throw an Unmodifiable exception

Upvotes: 1

Tim Bish
Tim Bish

Reputation: 18366

This excerpt is referring to the JMS client implementation as the JMS Provider here and it is telling you that once you call send using the asynchronous API you no longer control the Message until such time as the asynchronous completion is notified either with a success or fail event.

The client will often times use an internal "read-only" flag on the send call to tag that the message is now not to be touched by the client code and will reset the read-only state back to read / write after the send call completes one way or another.

Upvotes: 2

Related Questions