Guillaume CHAUVET <[email protected]> writes: > Hi Knut, > > Thank you for your reply. So now, I use the ClientConnectionPoolDataSource as > DataSource into my OpenJPA configuration. > But getPooledConnection[X](...) methods aren't invoked by the ORM, only > getConnection[X]() methods inherited from ClientBaseDataSource are invoked.
Right, it will only work if your application has enough control over how the connections are created. It would have to call getPooledConnection() on the data source, register a listener on the PooledConnection, and then call getConnection() on the PooledConnection to get an actual JDBC Connection instance. > I don't know if this is the good behaviour, should getConnection[X](...) > methods be overloaded into ClientConnectionPoolDataSource and return > getPooledConnection[X](...). getConnection() ? I'm not sure. The JDBC specification isn't very explicit on what getConnection() should do in a ConnectionPoolDataSource. But even if it did return getPooledConnection().getConnection(), the Connection interface doesn't provide any method to get a handle to the PooledConnection, so there wouldn't be any way to register the listener. What might work, is if you write your own little DataSource class whose getConnection() method calls ClientConnectionPoolDataSource.getPooledConnection(), registers a listener on the PooledConnection instance, and finally calls getConnection() on the PooledConnection. The ORM might be able to use that DataSource instead of Derby's DataSource. -- Knut Anders
