On Jan 16, 2008, at 8:43 PM, Dain Sundstrom wrote:
How about using a doubly weak map?
Commons collections has one that can be forked
http://commons.apache.org/collections/api-2.1.1/org/apache/commons/collections/ReferenceMap.html
Google has one also.
I supplied the PCRegistry.deRegister() patch (see https://issues.apache.org/jira/browse/OPENJPA-285
and http://www.nabble.com/PCRegistry-ClassLoader-memory-leak-td11631448.html)
. I certainly agree that it's a less than desirable solution. However,
I didn't come up with a better one (and still use the PCRegistry
structure). Apologies for not thinking of the OpenEJB implications at
the time...
It would take me a bit to swap everything back in, but pretty sure
that a doubly weak map won't work (and that I tried it). IIRC, the
only reference to PCRegistry$Meta object instances are via the
PCRegistry._metas map. If the _metas map is doubly weak, the Meta
objects can be GC'ed at any time... And bad things happen.
Happy to be proven wrong...
--kevan
-dain
On Jan 16, 2008, at 5:27 PM, Patrick Linskey wrote:
I guess we could have a setting of some sort to enable reference
counting, but this only works in the simple case, when classes are
only used by classloaders that involve a persistence unit, and in
which the usages are coincident.
I think that weak refs don't work because we already use a weak ref
to
a class somewhere else, and adding a weak ref from class to
classloader would effectively harden the ref to the class, and thus
to
the classloader.
-Patrick
On Jan 16, 2008 5:02 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
Hummm, didn't an EMF have to say "I need this class enhanced"? If
so,
can't you remember which EMFs wanted that class enhanced, and when
they close, delete the reference? Alternatively, how about a weak
reference?
Specifically, this type of explicit API makes it difficult to
integrate with OpenJPA in a generic way. This is the same problem
that Commons Logging had until recently when they added a weak
reference to the class loaders.
-dain
On Jan 16, 2008, at 4:56 PM, Patrick Linskey wrote:
The problem is that the registration happens during class load,
which
is unrelated to EMF closure.
-Patrick
On Jan 16, 2008 4:19 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
I'm getting the following class loader leak from PCRegistry.
java.net.URLClassLoader
<loader> of
org.apache.openejb.test.entity.cmp.ContextLookupCmpBean
pcSuper of org.apache.openjpa.enhance.PCRegistry$Meta
hard of
org.apache.openjpa.lib.util.concurrent.ConcurrentReferenceHashMap
$WeakEntry
[15] of
org.apache.openjpa.lib.util.concurrent.ConcurrentReferenceHashMap
$Entry[47]
table of
org.apache.openjpa.lib.util.concurrent.ConcurrentReferenceHashMap
_metas of org.apache.openjpa.enhance.PCRegistry
I noticed that PCRegistry does have a deRegister(classloader)
method,
which I assume would release the resources, but I'm curious why
the
resources aren't automatically released when I call EMF.close().
Is there anyway, we can have PCRegistry automatically release the
class references, so I don't have to call an OpenJPA specific api?
Thanks,
-dain
--
Patrick Linskey
202 669 5907
--
Patrick Linskey
202 669 5907
