I have found one thing in the PooledSession that is probably worth
keeping in a Cache. The Consumer which waits for reply messages. At the
moment in the JMSConduit a request is sent out then the thread waits
synchronously for a reply on the consumer of the pooled session.
Wouldn´t it be possible to simply start one or more consumers
permanently to listen for reply messages each in a ListenerThread and
then correlate the reply messages to the request messages. So we do not
need a pool as each listener will permanently have it´s own thread.
Best regards
Christian
Christian Schneider schrieb:
Hi,
I am just working an a refactoring of the JMS Transport. In the module
there is an implementation of a session cache.
As we later want to switch to SpringTemplate and Spring
ListenerContainer I want to get rid of as much pooling implementation
as possible.
So my question is: Do we really need a session cache. As far as I
understood from JMS specs sessions are lightweight short lived objects.
So I think it would not harm to create a new session for each message
and destroy it later. The same is true for producers.
The connection on the other hand has to be cached as it is costly to
create. I think the connection could be stored as a simple attribute
of JMSConduit or JMSDestination.
As far as I know it is thread safe too.
What is your knowledge about this?
Best regards
Christian
--
Christian Schneider
---
http://www.liquid-reality.de
