db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Kroeker <raykroe...@gmail.com>
Subject Re: Derby causing a classloader leak
Date Wed, 14 Apr 2010 01:39:43 GMT
My concern is that there is NO guarantee as to WHEN the finalizers on
objects are called.  You can call gc until you're blue in the face and
there is no onus on the JVM to finalize your objects.

Same goes for loaded classes, they get removed when the JVM just
bloody well feels like it, so my though on these as indicators of a
leak is low.

Can you provide a sample of your test with the loop?  I would lean
towards Alan's response of a physical resource not being released by
the code-within-the-loop.  I have had good luck load testing
applications using both embedded and network drivers for version
10.2.2.0 (I know it's older) and every time it's been the app (or
connection pool) holding on to statements/results or connections.

Good luck.

Raymond

On Tue, Apr 13, 2010 at 02:08, Alan Burlison <Alan.Burlison@oracle.com> wrote:
> On 13/04/2010 01:02, Jason von Nieda wrote:
>
>> And to Alan, yes, I am closing the statement. I've also tried explicitly
>> closing the statement and creating a new one for each command. That also
>> fails.
>
> OK, was just a thought - I've seen leakage in the past because of that.
>
> --
> Alan Burlison
> --
>



-- 
---------------------------------------------------------
Raymond Kroeker

Mime
View raw message