db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: question: is is possible to identify open resources?
Date Tue, 14 Sep 2010 20:54:04 GMT
Ron Rudy <ronchalant@gmail.com> writes:

> On Tue, Sep 14, 2010 at 2:01 PM, Patrick Holthuizen <patrick@eaze.org> wrote:
>>>
>>> On Tue, Sep 14, 2010 at 1:07 PM, Patrick Holthuizen <patrick@eaze.org>
wrote:
>>>
>>>>> Is there a specific reason why you don't want to close the connection?
>>>>>
>>>>>
>>>> Just performance.
>>>>
>>>>
>>>
>>> What I'm assuming you're looking for here is leaks to ensure that all
>>> resultsets/statements/etc. are closed, yes?
>>>
>>> In theory what you COULD do is wrap your connection object and have it
>>> produce something like a "TraceableStatement" and "TraceableResultSet"
>>> that likewise wrap the implementation returned by the Derby connection
>>> object.  Then at the end interrogate these to see if any remain
>>> unclosed.
>>>
>>> That would be also pretty extensive, but there may very well be a
>>> project out there dedicated to that sort of "tracing" JDBC
>>> implementation to help development debug resource leaks.  You might
>>> want to take a look around.
>>>
>>> -Ron
>>>
>>
>> Your assumption is correct. I think it is a good idea to look around the
>> web for an existing solution. I just hoped Derby has a mechanism already
>> built in because Derby also has to keep track of all open statements and
>> result sets. The information I need is somewhere in Derby but I assume
>> it is not exposed in the API.
>>
>> I will not prefer your solution of wrapping the existing objects, the
>> objects are already wrapped in Data Access and SqlStatement classes but
>> these classes are exactly the classes to be tested.
>>
>
> What I mean is that there may be a wrapper implementation of the JDBC
> spec that will envelope the classes you specify.  Often this is done
> with a change in DBUrl, something like "jdbc:tracingdriver:(my
> original jdbc url)".  Many pooling implementations take this approach
> as well.

You can also track closing of Statements by retrieving a PooledConnection
from org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource and
registering a StatementEventListener. You'd still need to write your own
wrapper around Connection to track opening of Statements, though.

-- 
Knut Anders

Mime
View raw message