db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Rudy <ronchal...@gmail.com>
Subject Re: question: is is possible to identify open resources?
Date Tue, 14 Sep 2010 18:05:21 GMT
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.


View raw message