Hi Filip, Yes, we are aware that the API allow us to write our own JdbcInterceptor so we are writing an interceptor to handle this issue by creating a proxy for the statement and resultSet.
We will attach it to the bugzilla ticket as a workaround, but we think the issue should be fixed inside the jdbc-pool (it could be a "fixed" JdbcInterceptor). Thanks, Guillermo On Wed, Dec 16, 2009 at 12:19 AM, Filip Hanik - Dev Lists < devli...@hanik.com> wrote: > On 12/15/2009 10:34 AM, Guillermo Fernandes wrote: > >> Hi, >> >> I'm using ddlutils 1.0 and tomcat jdbc pool 1.0.7.1 and I getting an error >> due to a connection is closed and the pool is not aware of that. >> Basically the issue is that ddlutils has a resultset iterator and when it >> finishes it closes the connection by getting it from the * >> resultSet.preparedStatement.connection* and the connection returned is not >> the proxy that the pool has created. >> >> > wow, that seems backwards, but since the API allows you to do so, I would > guess its a valid use case. > > So the issue happens when another client retrieves a connection from the >> pool because the pool returns a connection that was actually closed. >> >> > validationQuery="..." and testOnBorrow="true" would take care of this as a > work around for now. > > Why tomcat jdbc pool is not creating proxies for preparedStatements and >> resultSets like commons-dbcp? >> >> > performance of course, the lesser the better. > SlowQueryReport interceptor already has an example of this, so its doable. > > Is there any other way to address this issue? >> >> > see work around above > > Filip > >> Thanks, >> Guillermo >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
