Hi Erik,The JDOImplHelper cannot use soft references to registered classes because it wasn't clear what would happen if the class is garbage collected and then used again. We wanted to make sure that the JDOImplHelper would always have the metadata for the class.
To solve this problem, we added the methods unregisterClass and unregisterClasses that allow the JDO implementation to explicitly remove the classes from the JDOImplHelper. It's not automatic (the implementation needs to have some kind of life cycle manager) but it seems to work in practice (e.g. in application servers).
We can open this up if people with strong knowledge of the behavior of the class loader can take a look at it.
Craig On Mar 6, 2006, at 8:25 AM, Erik Bengtson wrote:
Let me rewrite in English ;) Hi,If applications using short lived classloaders register PC classes, and later on these classloaders are released. Classes should be GC together with the classloaders, but the JDOImplHelper is holding strong references to theseclasses. What is the strategy to take to avoid a memory leak in JDOImplHelper? Regards, Quoting Erik Bengtson <[EMAIL PROTECTED]>:Hi,What happens if the classes registered in a JDOImplHelper are unloaded or ifan attempt to GC the classloader?Later on the same class loaded by a second classloader, third, forth and soon?Is there a memory leak here since the classloader will not be garbage collectthe classes as we have a strong references to the classes? Regards, Erik Bengtson
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
