1 of 1 people found this helpful
you shouldnt be using it concurrently, underneath it uses the core API, like most messaging API (JMS included) it should always be used single threaded
Andy, thanks for the response.
if that being the case, usually on client side what is the best approach to deal with concurrent request. Do I need to do a pool of session similar to connection pool?
Or can I possibly use a queue approach with single thread to dispatch request and notify response with unique request id because establishing many sessions seem to be a bit overkill
You need a session per thread since sessions are single-threaded (as Andy mentioned). Whether or not you implement that with a pool or some kind of "queue" pattern doesn't really matter from my perspective.
As everybody mentioned a Session represents the interaction of a thread. you can switch the context of a thread.. as long as you don't access it concurrently. (that goes to anything used within the session).