arjan tijms [http://community.jboss.org/people/atijms] replied to the discussion "Does the JBM bridge uses a connection pool?" To view the discussion, visit: http://community.jboss.org/message/549953#549953 -------------------------------------------------------------- I was struggeling with the same thing, and as it appears the Bridge doesn't use a connection pool, but uses a different kind of pattern so it actually doesn't really need one. This pattern is not unlike e.g. a request queue for AJAX requests in JSF 2 and RichFaces, where instead of letting each part of the code sent something on its own (with or without a connection pool), all requests are collected in a single queue and sent out in batches by a single thread. In fact, in our own software I have implemented the exact same pattern. We have tens to hundreds of small write requests per second, and originally we let each thread where the write request originated write to a DB directly. Of course there was a connection pool in between (for JDBC these are actually easy and actually work ;) ). This didn't scale very well, even though a connection pool was thus used. So I rebuild the architecture to let all threads post their write requests to a single queue, which is read by 3 threads having a single fixed connection each to the DB, via which they sent the write requests in batches. (in case of many cores in both the client and DB and having sufficiently fast storage in the DB, we found 3 consumers for this queue to work more optimally than 1). I scanned through the org.jboss.jms.server.bridge.Bridge code and found it basically does the following (omitting details about xa/non-xa, username/no username, etc): 1. Get source and target destinations from JNDI 2. Get source connection factory from JNDI1. Create connection 2. Create session 3. Create consumer(sourceDestination) 3. Get target connection factory from (remote) JNDI1. Create connection 2. Create session 3. Create producer(null) 4. consumer.setMessageListener(SourceListener) 5. SourceListener onMessage:1. Get global lock 2. Put message in list 3. If batch size reached1. For each message in list1. producer.send(targetDestination, message) That's basically it. Apart from a very small hack to optimize forward_mode_xa if the source is jboss messaging, it's all just the pure and simple JMS API that's being used by the bridge. No JBoss internal magic and no JCA pools for remote connections. Nevertheless, even in this case where the bridge uses a single fixed connection, it might be handy to have a connection pool anyway. Namely, such a pool could take care of validating that connections are still valid and destroy a connection and reconnect if needed. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/549953#549953] Start a new discussion in JBoss Messaging at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]