First off, the primary thing they're suggesting against is something like:
[code]
for(Item i : lotsOfItems) {
connection = queueConnectionFactory.createConnection();
session = connection.createSession(false, javax.jms.Session.AUTO_ACKNOWLEDGE);
MessageProducer messageProducer = session.createProducer(myQueue);
ObjectMessage message = session.createObjectMessage();
message.setObject(i);
messageProducer.send(message);
session.close();
connection.close();
}
[/code]
I mean, that's just crazy. At least move the connection out of the loop, eh?
Here's the deal.
Your MDBs and your connection pool are intimately related.
Let's consider the simple out of the box scenario #3 -- ConnectionFactory injected in each bean as it comes and goes via the @Resource annotation.
If you have, say, 10 MDBs configured in your container and 5 connections, then, guess what, you'll only ever have 5 MDB's running at any one time, because each MDB needs a connection. The rest will block waiting for a connection.
Doesn't make a whole lot of sense to have more MDBs than Connections in that case then, does it?
If you have more connections than MDB's, then in scenario #2, the MDBs will hit the pool for their 10 connections (in this case), and they're done. The pool serves other consumers out of its remainder, and the MDBs enjoy their own, "dedicated" connection.
If you find this performs better than #3, then more power too you. #3 is nice because connections will end up geting closed regularly, which the servers may enjoy (who knows what the servers tie to connections, and whether servers like long lived connections or short lived connections). But you can "close occasionaly" in scenario 2 if that becomes an issue.
If your going to be moving a lot of traffic, then I'd start playing with the scenarios and start moving your traffic early rather than later. Because, in the end, it doesn't matter what we say, or what we want, all that matters is what behavior performs best for you and your application.
I would pick the solution that lets the container do as much of the heavy lifting as you're willing to let it, because that's what the container is for. IMHO, I like #2, but I'd work with #3 until it proves through testing that it simply won't work. If it does work, then the container is doing what it's supposed to do, and you get to enjoy those benefits rather than work around them.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=240532