db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: JDBC Driver : connection listener
Date Thu, 18 Jul 2013 10:20:25 GMT
Guillaume CHAUVET <guillaume.chauvet@qualiformed.com> 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

Mime
View raw message