0
votes

Section 2.14 of JMS 2.0 Spec:

JMS could have required that all its objects support concurrent use. Since support for concurrent access typically adds some overhead and complexity, the JMS design restricts its requirement for concurrent access to those objects that would naturally be shared by a multi-threaded client. The remaining objects are designed to be accessed by one logical thread of control at a time.

Supports Concurrent usage: Destination, ConnectionFactory, Connection

Does not support concurrent usage: JMSContext, Session, Producer, consumer

Not sure why thread safety of Message is not discussed in spec?

EDIT

Is Message thread safe? Can two threads share it without race?

No. Message is not thread safe. It should not be shared between threads.

1
Why would you need access to the same Message object in multiple threads? In particular modify a Message in multiple thread. You could allow concurrent reads for multiple consumers. - Peter Lawrey
It would we safe to share the message between threads, unless they try to modify the message - Ankur Shanbhag
scenario - two threads processing payload and setting message property. Can it be done in parallel without race? - Amit G
@AmitG That is a very strange use case. But no, it can't be done with a JMS message. - nos
@AmitG See chapter 6.2 where it says that any object created by a session is not thread safe. Messages are created by a session (either explicitly, or implicitly from another object created by a session). You can do your own locking to access it from multiple threads though. - nos

1 Answers

1
votes

Message is not thread-safe. Message is mutable, it has setters, so while one thread is using a Message another thread can interfere and change it.