Question

I think this is a stupid question, but I can’t quite find the answer I’m looking for in the JMS getting started guide, or indeed elsewhere on the web. This jGuru post suggests that thread safety in the following scenario is up to the application designer.

Scenario

Consider an Object as an attribute of HttpSession. This object is of type ProductQuote.

In a Java Servlet, I take some input from the request and set them to fields in a new instance of ProductQuote and then use another class of mine to push the same ProductQuote instance on to a JMS Queue.

On a separate thread, this object is popped from the queue via the container, and passed to my message driven bean (“MDB”) that implements MessageListener via the onMessage(Message message) method. This particular implementation of the MessageListener interface will mutate a field in the instance and then discard the message, executing cleanly.

Question

Is it possible that the instance of ProductQuote pushed to the queue in the Servlet the exact same instance that is consumed by the MDB in another thread?

I am assuming the reverse is also possible (if not always; I’m trying to fill a gap in my knowledge): that an instance pushed to a queue/topic is not the same instance as that passed to consumers.

Edit
For additional clarification, I am pondering thread safety in the given scenario, where an object in the session could be modified at the same time an MDB is modifying/reading it.

Forgive the stupid question.

Answer 1

The answer is defined in the JMS specification and I quote:

Note that the setObject method of ObjectMessage places a copy of the
input object in a message

Given that any JMS provider — in my case BEA Weblogic — would have to adhere to this, I am confident the thread-safety concern in my original message is unfounded: objects that are in ObjectMessage instances are copied and therefore the threat of concurrent modification does not exist.

Edit

I should have read the Javadoc too:

public void setObject(Serializable object)
               throws JMSException

Sets the serializable object containing this message’s data. It is
important to note that an ObjectMessage contains a snapshot of the
object at the time setObject() is called; subsequent modifications of
the object will have no effect on the ObjectMessage body.