Actually I see this as well.  I had over 690,000 of these laying around, and I am using Derby 10.5.3.  I don't know if I have a test case that I can share, but within my program when I profile it I see a lot of these.  They look like they are weakly referenced, but the GC doesn't want to give them up.


On Wed, Feb 17, 2010 at 6:34 PM, Knut Anders Hatlen <> wrote:
Sumedh Wale <> writes:

> Hi
> I noticed OOM issues in one of the test runs that creates quite a good
> number of PreparedStatements. Looking at the hprof dump and the code,
> it looks like GenericPreparedStatements are being held on to by
> BasicDependencyManager even after having being expired from LCC's
> CacheManager. I looked at JIRA but did not find any existing bug for
> this -- is it a known issue? One fix can be to explicitly invoke
> DependencyManager#clearDependencies() for the GenericPreparedStatement
> from CachedStatement#clearIdentity(). This is with 10.4.x and I have
> not yet tried with latest 10.5 release.

Hi Sumedh,

I haven't heard about this issue before, so if you still see it with
10.5 it would be great if you could file a bug report with instructions
on how to reproduce it.


Knut Anders