I have attached the interceptor to the bugzilla ticket. Actually, it extends the AbstractStatementInterceptor.
Guillermo. On Wed, Dec 16, 2009 at 4:47 PM, Filip Hanik - Dev Lists <devli...@hanik.com > wrote: > correct, there is an AbstractStatementInterceptor that you would extend in > order to write such an extension. > > Filip > > > > On 12/16/2009 06:02 AM, Guillermo Fernandes wrote: > >> 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 >>> >>> >>> >>> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
