Currently calls to getPooledConnection() and getXAConnection on the pooled DataSource return the same handler as calls to getConnection(). This does not correctly implement these interfaces. Per the documentation (http://docs.oracle.com/javase/6/docs/api/javax/sql/PooledConnection.html): "A PooledConnection object represents a physical connection to a data source" and the documentation for the close method: "Closes the physical connection that this PooledConnection object represents. An application never calls this method directly; it is called by the connection pool module, or manager." The getPooledConnection() and getXAConnection() methods should return the physical connection provided by the driver (if it implements the interface), wrapped in a handler that will provide the pool handler when the getConnection() method is called. For example, getPooledConnection().getConnection().close() should return the connection to the pool, not close the physical connection.
(In reply to Jonathan Pierce from comment #0) > For example, getPooledConnection().getConnection().close() should return the > connection to the pool, not close the physical connection. http://docs.oracle.com/javase/7/docs/api/javax/sql/ConnectionPoolDataSource.html#getPooledConnection() -> Attempts to establish a physical database connection that can be used as a pooled connection. http://docs.oracle.com/javase/7/docs/api/javax/sql/PooledConnection.html#getConnection() -> Creates and returns a Connection object that is a handle for the physical connection that this PooledConnection object represents. Jonathan, thank you for your report. Overall, I do believe that the fix is that org.apache.tomcat.jdbc.pool.DataSource should NOT implement the javax.sql.ConnectionPoolDataSource interface. The ConnectionPoolDataSource/PooledConnection interface are to be used by pool, instead of being provided by pool. "An application programmer does not use the PooledConnection interface directly; rather, it is used by a middle tier infrastructure that manages the pooling of connections." I'd like to learn more about your use case, and why it is using that interface at all.
Filip, Sorry for my delayed response. I believe you are correct that the tomcat-jdbc library need not directly expose the PooledConnection interface, as the interface is designed to only be used by connection pooling containers/libraries. However, my particular use case is with XADataSource and XAConnection. The XAConnection interface extends the PooledConnection interface, so I ran into the problem there. The expectation is that only special XA handling logic will use the XAConnection and when it is complete it will call XAConnection.getConnection() to acquire a Connection object, which gets passed to the standard JDBC logic. I do think it makes sense for the tomcat-jdbc library to expose the XA interfaces. So I think a fix may be in order, so that XAConnection.getConnection() returns a proxy on the physical connection (Connection interface) which when closed will return the the Connection to the pool.