Why are JMS specs designed in the way so that Session Object cannot be used by concurrent threads when Connection object from which Sessions are created are thread safe(Shared by thread)?
JMS Session object is typically used for Transactions. And we all know transactions are thread specific and can't span across threads. Hence a transacted JMS session can't be used across threads. I believe for this reason JMS specification says session is not thread safe.
JMS 2.0 Spec
page 25
There are two reasons for restricting concurrent access to sessions.
First, sessions are the JMS entity that supports transactions. It is very difficult to implement transactions that are multi-threaded.
Second, sessions support asynchronous message consumption. It is important that JMS not require that client code used for asynchronous message consumption be capable of handling multiple, concurrent messages.
In addition, if a session has been set up with multiple, asynchronous consumers, it is important that the client is not forced to handle the case where these separate consumers are concurrently executing. These restrictions make JMS easier to use for typical clients. More sophisticated clients can get the concurrency they desire by using multiple sessions. In the classic API and the domain-specific APIs this means using multiple session objects. In the simplified API this means using multiple JMSContext objects.
© 2022 - 2024 — McMap. All rights reserved.