1. Does anybody know if a Java Application running in an explicitly kicked-off Thread will accept a JMS Client string?
2. If so, are there any limitations on the message received by the client or the subsequent acknowledgements?
3. Does it make any difference to the Java Application running in a thread, if the JMS Client, Connection and Session are declared in the Threaded code or should the Connection be declared outside of the Thread with only the Session declared in the Thread?
4. Is the receipt of the JMS message considered an "atomic" opertion in a Java Threaded environment?
I may be off base about your question but here goes an attempt to answer the question:
First, according to the JMS Specification JMS Objects Connection and ConnectionFactory are safe to use in a multi-threaded environment, but Session, MessageProducer, and MessageConsumer are not.
Here is what it means:
You can generate a Connection and share it between multiple Threads, and expect it to work fine.
You can generate a Session in a Thread, and expect it to work as normal.
A Session should be be limited to a single Thread. Multiple Threads accessing the same Session can cause several erroneous behaviors, and when multiple asynchronous consumers are added to the same session properly, they are dispatched to serially (not in parallel).
If you want multiple consumers running in parallel (in different Threads) you should use multiple Sessions - one for each Thread.
Since Sessions and MessageConsumers are not considered safe for multi-threading, I would assume that Message Receipt was not atomic. But I didn't find that specifically stated.
Dennis M Kavanagh
Joined: Mar 26, 2007
Can I ask also if you have any experience with OpenJMS?
I am wondering whether or not it is still a viable technology to
select as a JMS Implementation Provider?