With respect, that doesn't really get me anywhere.
<p>There are defined semantics that a DataSource must have, and that a ConnectionPoolDataSource must have. Both PostgreSQL and MySQL ship multiple drivers, at least one of which (in each case) implements javax.sql.DataSource, and at least one of which (in each case) implements javax.sql.ConnectionPoolDataSource. Then their documentation claim different things, viz. that in MySQL's case you should use the regular old javax.sql.DataSource, and in PostgreSQL's case you should use the javax.sql.ConnectionPoolDataSource implementation.</p>
<p>Someone here must be wrong. My problem is figuring out who.</p>
<p>The reason I see this as a problem is because the Javadocs of ConnectionPoolDataSource do not explicitly say whether:</p>
<ul>
<li> ConnectionPoolDataSource is a way of acquiring connections that fronts its own vendor-supplied pool or</li>
<li> ConnectionPoolDataSource is the interface you use when you are on an application server or some other bit of machinery that provides its own pool management plumbing.</li>
</ul>
<p>Specifically, the javadoc says this:
<blockquote>"A factory for PooledConnection objects. An object that implements this interface will typically be registered with a naming service that is based on the JavaTM Naming and Directory Interface (JNDI)."</blockquote></p>
<p>O...K.</p>
<p>Given that ConnectionPoolDataSource has an API none of us is really used to--namely getPooledConnection() instead of the ubiquitous javax.sql.DataSource#getConnection()--I'm <i>guessing</i> (but that's all I'm doing) that it's for use in application servers, i.e. platforms that have a pooling mechanism already, and that it makes it easier for those application servers to acquire a physical connection, or makes it more clear, or something. If that's right, then the PostgreSQL guys are right, and you should always use a ConnectionPoolDataSource implementation where possible.</p>
<p>Of course when I actually DO this with MySQL's drivers, I occasionally get an error from Glassfish's pooling mechanism that says that a physical connection is not usable--some Googling suggests that this is due to the fact that a ConnectionPoolDataSource implementation has returned a <i>pooled</i> connection of some kind when a physical one was asked for. I do not know about the internals of the Glassfish pooling mechanisms.</p>
<p>Sorry for the long-windedness; I wanted to make sure that I was giving the full background behind my question. I hate just trying something, watching it break, shrugging, and then doing The Other Thing because hey, the First Thing broke, so The Other Thing must be the way to go.</p>
<p>Best,<br/>
Laird</p>
[Message sent by forum member 'ljnelson']
http://forums.java.net/jive/thread.jspa?messageID=484121