requires relatively
long-term exclusive use of a session, a consumer with a MessageListener for
the JMS destination specified for the port, and an unidentified producer
to send the request message
server-side send: each dispatch of a twoway request requires relatively
short-term exclusive use of a session and an indentified producer (but
not a consumer) - note that the session used for the recieve side cannot
be re-used for the send, as MessageListener usage precludes any synchronous
sends or receives on that session
So on the client-side, pooling of sessions is bound up with pooling
of temporary reply destinations, whereas on the server receive side
the benefit of pooling is marginal as the session is required from
the point at which the port was activated until the Bus is shutdown
The server send side resembles the client side,
except that a consumer for the temporary destination is never required.
Hence different pooling strategies make sense ...
client-side: a SoftReference-based cache of send/receive sessions is
maintained containing an aggregate of a session, indentified producer,
temporary reply destination & consumer for same
server-side receive: as sessions cannot be usefully recycled, they are
simply created on demand and closed when no longer required
server-side send: a SoftReference-based cache of send-only sessions is
maintained containing an aggregate of a session and an indentified producer
In a pure client or pure server, only a single cache is ever
populated.