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.
Hi Sumedh,Sumedh Wale <firstname.lastname@example.org> writes:
> 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.
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.