I may have found the real problem. BlobBuffer objects are referenced by
oracle.toplink.essentials.sessions.DatabaseRecord, which is probably
part of 2nd level cache. It turns out that TopLink Essentials has a
stripped down cache invalidation policy:
"Currently the session cache is controlled by Weak or Soft
references(see cache-type options). So we cannot invalidate cache as
time/daily basis or per query. TopLink provides several invalidation
policies, but currently TopLink Essentials is lack of this. "
http://weblogs.java.net/blog/guruwons/archive/2006/09/understanding_t_1.html
So, if I disable the TopLink Essentials 2nd level cache then the problem
should go away.
Thanks,
Ryan
Ryan de Laplante wrote:
> Hi,
>
> I`ve been trying to figure out a memory leak for a couple of months.
> The latest heap dump pointed out that there are 122802 instances of
> byte[] (over 600 MB). Most of the instances I looked at are
> referenced by BlobBuffer. I see that the only BlobBuffer class in
> memory is from the jTDS jdbc driver (for MS SQL Server 2005). There
> are 95316 instances of net.sourceforge.jtds.util.BlobBuffer that
> reference most of these byte[] arrays.
>
> BlobBuffer instances are referenced by 12358 instances of
> oracle.toplink.essentials.sessions.DatabaseRecord. The trail ends
> there. I'm wondering if this is cache? Does JPA 1.0 RI have no
> limits on cache size by default? No expiry on cached records? What
> else can I do to further diagnose?
>
>
> Thanks,
> Ryan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>