ic.close(); And the onMessage has got JDBC calls and closing the connection once done, etc.
QUESTION: Is it going to be inefficient to have such JDBC stuff for a MDBs that listens to hundreds of messages from a given Queue? What's your recommendation....to have them passed on to a pool of stateless beans to handle to JDBCs? Thank you.
My recommendation would be to break out the database logic into a DAO and directly call that from the MDB. I wouldn't go with a Session Bean unless it provides some type of concrete benefit for you (the need for declarative transactioning, security, etc.). In regards to your performance question... how could using a Session Bean be faster than straight JDBC? Either way the same JDBC code is going to execute, however with a Session Bean you will need to factor in the added overhead of EJB.