Question

I have a stand-alone JMS app that subscribes to several different JMS topics. Each topic has its own session and onMessage() listener. Each onMessage() method updates a common current value table – all the onMessage() methods update the same current value table.

I’ve read that the onMessage method is actually called on the JMS provider’s thread. So, my question is: if all these onMessage() methods are called on a separate thread than my app, doesn’t this present a concurrency problem since all these threads update a common CVT? Seems like I need to synchronize access to the CVT somehow?

Answer 1

Short answer to your question: YES, you need to take care of concurrency concerns when your JMS code is updating some common in-memory object.

However, I’m not sure what you mean by “common current value table”? If this is some database table, then database should take care of concurrency issues for you.

EDIT: it turned out that “common current value table” is a common in-memory object. As I mentioned earlier, in this case you need to handle the concurrency concerns yourself (Java concurrency tutorial).

There are mainly two approaches to this problem:

• synchronization – suitable if you have low-contention or you are stuck with some non-threadsafe object, then your best choice is synchronization.
• high-level concurrency objects that come with the JDK – best fit if you have high-contention and you are using some class from regular collections; just swap in an instance of concurrent collections.

In any case, it is highly recommended to do your own testing to choose the best approach for you.

If you would be dealing with expensive to create non-threadsafe stateless procedural code (no storage of data involved) then you could also use object pooling (e.g. Commons Pool), but this is not relevant in your current issue.

JMS onMessage() method is always called by the JMS provider’s thread (also known as asynchronous calling).