tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillermo Fernandes <gsfernan...@gmail.com>
Subject Re: tomcat jdbc pool is not proxying resultSets and preparedStatements
Date Sat, 19 Dec 2009 16:50:17 GMT
You're welcome

On Thu, Dec 17, 2009 at 11:55 AM, Filip Hanik - Dev Lists <
devlists@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<
>> devlists@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<
>>>> devlists@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message