With Oracle and other products, teams that I have worked with seem to always encounter this same problem: too many connections, even though the developers think they did everything right to use connection pooling. e.g. XAConntection object via getXAResrouce. I haven't had my hands in that particular code, however. I am concerned that as I go forward with EJB 2.x implementations I will run into the same problem. I hope that EJB "knows" how to avoid creating new connections using the underlying pool, rather than its "own" object pool. Thanks for any insights, anyone. PS. I'm looking forward to the new (3rd edition) of the JDBC book; maybe it will address EJB somewhat more that the 2nd ed.
Juan Rolando Prieur-Reza, M.S., LSSBB, SCEA, SCBCD, SCWCD, SCJP/1.6, IBM OOAD, SCSA
Originally posted by john prieur: [...] too many connections, even though the developers think they did everything right to use connection pooling. e.g. XAConntection object via getXAResrouce.
If that is really what they do, they do exactly the wrong thing, and it's not surprising that they run into problems. As a developer, you don't touch XAConnection or PooledConnection directly. You just ask the application server to provide you with a DataSource, pull it out of JNDI, and get plain ol' Connection objects from that DataSource. XAConnection and PooledConnection are infrastructure classes for use in DataSource implementations. It is a mistake to think that JDBC classes implenting these interfaces provide any connection pooling functionality! Rather, they encapsulate physical database connections and provide some infrastructure for a connection pool implementation (ConnectionEventListener and getConnection()). They will be used behind the scenes by the DataSource that the application server provides you with. As the javadoc has it, An application programmer does not use the PooledConnection [or XAConnection -- PdH] interface directly; rather, it is used by a middle tier infrastructure that manages the pooling of connections.. Your team should probably not be touching it. They can use a run of the mill DataSource providing Connection objects, and let the application server worry about the rest. - Peter
The RDBMS, Oracle for example, supports connection pool. This is encapsulated by the connection pool interface(s), as nicely described by Peter. Now, when the EJB Container provides transparent database connections, it may or may not attempt to manage connections through its own object pool. Or it may "know" how to let the undelying database (Oracle for example) perform the pooling. I actually do not know to what extent the EJB Containers behave as I just described. Thanks for your feedback
Peter den Haan
Joined: Apr 20, 2000
I would be really surprised to find an application server that did not pool connections in its DataSources. - Peter
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com