You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Patrick Holthuizen <pa...@eaze.org> on 2010/09/11 10:16:33 UTC
question: is is possible to identify open resources?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I use Derby with an in-memory database for unit testing. All unit
tests share a single connection. Now I want to assert (not close) (in
the tear down of a unit test) that all result sets and statements used
during the test are properly closed. Is it possible to obtain all
resources related to a connection which are currently open?
Thank you in advance.
Sincerely,
Patrick Holthuizen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkyLOuEACgkQ2xeQKUlEiTbIlwCcDMlqnzmuVpnbERGKUOYRC3LL
tMIAniDkMI/pO3OAuwEQKUuenwI8WFRl
=Qc/F
-----END PGP SIGNATURE-----
Re: question: is is possible to identify open resources?
Posted by Patrick Holthuizen <pa...@eaze.org>.
> 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.
>
>
Thank you very much for your suggestion.
Re: question: is is possible to identify open resources?
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Ron Rudy <ro...@gmail.com> writes:
> On Tue, Sep 14, 2010 at 2:01 PM, Patrick Holthuizen <pa...@eaze.org> wrote:
>>>
>>> On Tue, Sep 14, 2010 at 1:07 PM, Patrick Holthuizen <pa...@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
Re: question: is is possible to identify open resources?
Posted by Ron Rudy <ro...@gmail.com>.
On Tue, Sep 14, 2010 at 2:01 PM, Patrick Holthuizen <pa...@eaze.org> wrote:
>>
>> On Tue, Sep 14, 2010 at 1:07 PM, Patrick Holthuizen <pa...@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.
-Ron
Re: question: is is possible to identify open resources?
Posted by Patrick Holthuizen <pa...@eaze.org>.
>
> On Tue, Sep 14, 2010 at 1:07 PM, Patrick Holthuizen <pa...@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.
Re: question: is is possible to identify open resources?
Posted by Ron Rudy <ro...@gmail.com>.
On Tue, Sep 14, 2010 at 1:07 PM, Patrick Holthuizen <pa...@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
Re: question: is is possible to identify open resources?
Posted by Patrick Holthuizen <pa...@eaze.org>.
> Is there a specific reason why you don't want to close the connection?
>
Just performance.
Re: question: is is possible to identify open resources?
Posted by Kristian Waagan <kr...@oracle.com>.
On 11.09.10 10:16, Patrick Holthuizen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> I use Derby with an in-memory database for unit testing. All unit
> tests share a single connection. Now I want to assert (not close) (in
> the tear down of a unit test) that all result sets and statements used
> during the test are properly closed. Is it possible to obtain all
> resources related to a connection which are currently open?
Hi Patrick,
Not that I'm aware of.
The only thing I can think of is issuing a rollback/commit, but that
doesn't guarantee that resources are closed. In the Derby test framework
we have utility methods keeping track of the resources, and they are
closed automatically (if not closed already) in the tear down method.
Is there a specific reason why you don't want to close the connection?
Regards,
--
Kristian
> Thank you in advance.
>
> Sincerely,
> Patrick Holthuizen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkyLOuEACgkQ2xeQKUlEiTbIlwCcDMlqnzmuVpnbERGKUOYRC3LL
> tMIAniDkMI/pO3OAuwEQKUuenwI8WFRl
> =Qc/F
> -----END PGP SIGNATURE-----
>