Re: OutOfMemoryErrors when testing Derby with DOTS

[Craig L Russell]

Hi Dan,

On Jan 31, 2006, at 12:04 PM, Daniel John Debrunner wrote:

Daniel John Debrunner wrote:

There's no guessing, if the application has a reference to an open JDBC object then it is still using it. If it no longer has a reference to a

open JDBC open then it is no longer using it and Derby must garbage
collect it.

I could have worded that last bit better.


of its resources during its garbage collection.

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

[So how does Derby clean up the dynamically compiled classes?]





Regards,

Craig

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. 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. I looked at the DOTS source code and it is generating a huge number of unique statements that differ only in the itemID (that is part of the SQL not a parameter). I also verified that the DOTS code only closes statements that execute successfully and return at least one row of data. So the "failed" statements are never closed. And there is no try{...} finally {...} to close result sets in case of exceptions. Maybe the fact that this code is now 3 years old since any maintenance is part of the problem.

Dan.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature