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). Dan.
