Ouch. I'm sorry.
Are you saying these are not being collected??
Wim
-----Original Message-----
From: glassfish_at_javadesktop.org [mailto:glassfish_at_javadesktop.org]
Sent: dinsdag 17 juni 2008 1:20
To: users_at_glassfish.dev.java.net
Subject: Re: RE: Trying to understand why toplink creates so many persistent
objects
Hi Wim,
Thanks for following up. Are you saying that using lazy loading comes along
with the minor disadvantage of memory leaks?
Unfortunately, I need to used lazy loading, and I cannot live with such a
memory leak.
The number of instances and size of my cached application objects (e.g.
DbItem) is fine. My issue seems to be with toplink internal objects like
these:
4: 179672 12936384
oracle.toplink.essentials.internal.identitymaps.HardCacheWeakIdentityMap$Ref
erenceCacheKey
9: 179763 5752416
oracle.toplink.essentials.internal.helper.ConcurrencyManager
13 million instances?
I am not sure how to explain why so many of these are created and referenced
for a long time (in perm gen state). It does not look like it is related to
how many of my application objects are created.
[Message sent by forum member 'jbelis' (jbelis)]
http://forums.java.net/jive/thread.jspa?messageID=280589
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net