users@glassfish.java.net

RE: RE: Trying to understand why toplink creates so many persistent objects

From: Wim V <wim_at_pizzastop.be>
Date: Tue, 17 Jun 2008 01:28:44 +0200

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