You're welcome On Thu, Dec 17, 2009 at 11:55 AM, Filip Hanik - Dev Lists < devli...@hanik.com> wrote:
> Thank you very much! > > > On 12/17/2009 07:11 AM, Guillermo Fernandes wrote: > >> 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 >>> >>> >>> >>> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
