Ron Rudy <[email protected]> writes: > 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.
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
