On Tue, Sep 14, 2010 at 2:01 PM, Patrick Holthuizen <[email protected]> wrote: >> >> On Tue, Sep 14, 2010 at 1:07 PM, Patrick Holthuizen <[email protected]> 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. -Ron
