The Session Pools they refer to were an optional part of the 1.0.2 JMS spec that allowed applications servers to pool jms sessions. Why? because each JMS session typically requires a dedicated dispatch thread (to deliver to MDBs) associated with it and most app servers want to be in control of thread creation. With the advent of JCA 1.5, the inbound contracts provide a much better way to interface JMS provides and MDBs so the Session Pool stuff has fallen out of favor. But in short, the connection/session pooling that we were talking about and the Session Pool stuff that document talks about are not the same stuff.
On 8/2/06, Paul French <[EMAIL PROTECTED]> wrote:
So why does Jencks for example create a pool of connections ? I know it pools sessions producers/consumers as well but in general if I use Jencks I will have many connections. There must be a reason? I've googled all over the place and I did see a quote on a web logic site which made no sense to me but it might to you http://edocs.bea.com/wls/docs81/jms/implement.html#1298531 > Note: Session pools are now used rarely, as they are not a required part > of the J2EE specification, do not support JTA user transactions, and are > largely superseded by message-driven beans (MDBs), which are simpler, > easier to manage, and more capable. For more information on designing > MDBs, see "Designing and Developing Message-Driven Beans" in Programming > WebLogic Enterprise JavaBeans > -- View this message in context: http://www.nabble.com/connections-or-sessions-tf2039029.html#a5614990 Sent from the ActiveMQ - User forum at Nabble.com.
-- Regards, Hiram Blog: http://hiramchirino.com
