https://issues.apache.org/bugzilla/show_bug.cgi?id=50571
--- Comment #7 from Jeremy Norris 2011-01-12 12:37:33 EST
---
Agreed, the actual bug is ConnectionState swallowing the exception on pool
startup, however I suspect that fixing it properly will require some of the
signatures to change.
In
https://issues.apache.org/bugzilla/show_bug.cgi?id=50571
--- Comment #6 from Filip Hanik 2011-01-12 11:11:22 EST ---
What I propose, is to fix the actual bug, of ConnectionState swallowing the
exception on pool startup.
And we fix this bug, without introducing new bugs by changing too many
signat
https://issues.apache.org/bugzilla/show_bug.cgi?id=50571
--- Comment #5 from Jeremy Norris 2011-01-11 21:18:57 EST
---
Sorry, the example code above should be for ConnectionPool.setupConnection().
The problem is the same though; do we continue invoking the interceptors on an
exception or not.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50571
--- Comment #4 from Jeremy Norris 2011-01-11 20:52:34 EST
---
(In reply to comment #3)
> protected void finalize(PooledConnection con) {
> JdbcInterceptor handler = con.getHandler();
> while (handler!=null) {
>
https://issues.apache.org/bugzilla/show_bug.cgi?id=50571
--- Comment #3 from Filip Hanik 2011-01-11 19:02:44 EST ---
I see, exceptions can't simply be propagated like that, since that would cancel
out events/code that needs to run.
protected void finalize(PooledConnection con) {
Jdbc
https://issues.apache.org/bugzilla/show_bug.cgi?id=50571
--- Comment #2 from Jeremy Norris 2011-01-11 18:36:33 EST
---
Hello,
This initial use-case I was needing was for SQLExceptions originating in
ConnectionState.reset() to propagate out of ConnectionPool.getConnection().
The rest of the cha
https://issues.apache.org/bugzilla/show_bug.cgi?id=50571
Filip Hanik changed:
What|Removed |Added
Status|NEW |NEEDINFO
OS/Version|