db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: OutOfMemoryErrors when testing Derby with DOTS
Date Tue, 31 Jan 2006 23:33:40 GMT
Craig L Russell wrote:

>> Daniel John Debrunner wrote:

>> If it no longer has a reference to a open JDBC open then it is no  longer
>> using it and Derby must allow it to be garbage collected and  release any
>> of its resources during its garbage collection.
> This is possible but can be tricky to implement. You need to be  careful
> inside Derby to only keep soft references to the result sets  and
> statements in order to allow the GC to work. And any use of the  soft
> reference needs to be guarded so as to avoid NPE. And there is  probably
> work to do when GC notifies you that the reference is going  to be
> collected.

Derby embedded handles garbage collection of JDBC objects correctly and
without using Soft references. The model is to only have references from
JDBC objects into Derby, not from Derby code to the JDBC objects.

> But even with soft references, you still have the issue of a huge 
> number of unique statements that have been compiled. And unless you 
> create a new class loader for each statement, you will have a huge 
> number of classes in memory.  

Yep, class loader per generated class (for a SQL statement).


View raw message