The problem with ConnectionEventListener is that the pooled connection
wrapper is not in the stack trace, so pool objects can't catch such
exceptions and are generally unaware of them. If you look at these lines:
at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
at org.gjt.mm.mysql.PreparedStatement.executeQuery(Unknown Source)
the exception is thrown by org.gjt.mm.mysql.Connection, and our pooled
connection wrapper is not involved.
The receiving end of the exception (DataNode) only has access to DataSource
interface that has nothing to do with ConnectionEvents. So much for JDBC3
"cool" features...
Of course we may create custom code for callbacks from DataNode to cayenne
pool (or to a generic delegate interface). This is just not as clean and
transparent as would like it to be. But this is the direction I am thinking
about.
Andrus
At 03:15 AM 1/5/2003 +0100, Holger Hoffstätte wrote:
>Andrus wrote:
> > (connection loss recovery)
> > BTW, this will probably not happen too soon, since there is a fundamental
> > problem in JDBC, notifying DataSource about connection errors. And
> > validating the connection every time it is checked out of the pool is going
> > to degrade performance.
>
>Hm? What about the javax.sql.ConnectionEventListener? When I read through
>the APIs I thought that this was made for exactly our required purpose. Is
>there anything wrong with it?
>
>Holger
This archive was generated by hypermail 2.0.0 : Sat Jan 04 2003 - 21:26:32 EST