You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Erik Bengtson <er...@jpox.org> on 2006/03/06 17:12:57 UTC
classes registered in JDOImplHelper unloaded
Hi,
What happens if the classes registered in a JDOImplHelper are unloaded or if an
attempt to GC the classloader?
Later on the same class loaded by a second classloader, third, forth and so on?
Is there a memory leak here since the classloader will not be garbage collect
the classes as we have a strong references to the classes?
Regards,
Erik Bengtson
Re: classes registered in JDOImplHelper unloaded
Posted by Jörg von Frantzius <jo...@artnology.com>.
Erik Bengtson schrieb:
> An alternative is making jdoNewInstance static, which would mean, no more calls
> to JDOImplHelper. That would definitily solve all issues related to it.
>
That would mean that the implementation needs reflection to call
different static jdoNewInstance() on different PersistenceCapable
classes. Static methods cannot be inherited and overriden in Java
(unfortunately, if you ask me).
Not a problem maybe?
jdoNewInstance static
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Erik,
On Mar 6, 2006, at 8:56 AM, Erik Bengtson wrote:
> An alternative is making jdoNewInstance static, which would mean,
> no more calls
> to JDOImplHelper. That would definitily solve all issues related to
> it.
Unfortunately, this would be a security exposure, since it would
allow a malicious user to create a new instance of a persistence
capable class without a security check. The current scheme is
designed for high performance in a secure environment.
Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: classes registered in JDOImplHelper unloaded
Posted by Erik Bengtson <er...@jpox.org>.
Craig,
> 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).
Let the JDO impl call unregisterClass on PMF.close, for example will solve the
problem because we could open another PMF and try to use the previous
unregistered classes.
An alternative is making jdoNewInstance static, which would mean, no more calls
to JDOImplHelper. That would definitily solve all issues related to it.
Quoting Craig L Russell <Cr...@Sun.COM>:
> 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
> > these
> > classes.
> >
> > What is the strategy to take to avoid a memory leak in JDOImplHelper?
> >
> > Regards,
> >
> > Quoting Erik Bengtson <er...@jpox.org>:
> >
> >>
> >>
> >> Hi,
> >>
> >> What happens if the classes registered in a JDOImplHelper are
> >> unloaded or if
> >> an
> >> attempt to GC the classloader?
> >>
> >> Later on the same class loaded by a second classloader, third,
> >> forth and so
> >> on?
> >>
> >> Is there a memory leak here since the classloader will not be
> >> garbage collect
> >> the 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: classes registered in JDOImplHelper unloaded
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Jörg,
On Mar 6, 2006, at 9:14 AM, Jörg von Frantzius wrote:
> Craig L Russell schrieb:
>> 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.
> When a class object is garbage collected, doesn't that simply mean
> that it needs to be loaded again and initialized the same way it
> was for the first time?
>
> There can't be any instances of that class anymore, so if anyone
> wants to do anything with a garbage collected class, he needs to
> load (and initialize) it first, registering the new class object
> with JDOImplHelper.
>
> To me it seems that there would be no problem with SoftReferences
> or even WeakReferences here.
To me as well, but I'd like to hear from others who have deep
understanding, or who can try changing the references to weak and
test exhaustively. ;-)
Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: classes registered in JDOImplHelper unloaded
Posted by Jörg von Frantzius <jo...@artnology.com>.
Craig L Russell schrieb:
> 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.
When a class object is garbage collected, doesn't that simply mean that
it needs to be loaded again and initialized the same way it was for the
first time?
There can't be any instances of that class anymore, so if anyone wants
to do anything with a garbage collected class, he needs to load (and
initialize) it first, registering the new class object with JDOImplHelper.
To me it seems that there would be no problem with SoftReferences or
even WeakReferences here.
Re: classes registered in JDOImplHelper unloaded
Posted by Craig L Russell <Cr...@Sun.COM>.
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
> these
> classes.
>
> What is the strategy to take to avoid a memory leak in JDOImplHelper?
>
> Regards,
>
> Quoting Erik Bengtson <er...@jpox.org>:
>
>>
>>
>> Hi,
>>
>> What happens if the classes registered in a JDOImplHelper are
>> unloaded or if
>> an
>> attempt to GC the classloader?
>>
>> Later on the same class loaded by a second classloader, third,
>> forth and so
>> on?
>>
>> Is there a memory leak here since the classloader will not be
>> garbage collect
>> the 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: classes registered in JDOImplHelper unloaded
Posted by Erik Bengtson <er...@jpox.org>.
Jorg,
It should work, regardless of a possible memory leak. It might be a problem of
your implementation, for instance, JPOX.
Quoting Jörg von Frantzius <jo...@artnology.com>:
> Holding strong references to class objects will also prevent any
> hot-deployment mechanisms in application servers from working. Finally I
> learned why it never worked for us ;)
>
> Erik Bengtson schrieb:
> > 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 these
> > classes.
> >
> > What is the strategy to take to avoid a memory leak in JDOImplHelper?
> >
> > Regards,
> >
> > Quoting Erik Bengtson <er...@jpox.org>:
> >
> >
> >> Hi,
> >>
> >> What happens if the classes registered in a JDOImplHelper are unloaded or
> if
> >> an
> >> attempt to GC the classloader?
> >>
> >> Later on the same class loaded by a second classloader, third, forth and
> so
> >> on?
> >>
> >> Is there a memory leak here since the classloader will not be garbage
> collect
> >> the classes as we have a strong references to the classes?
> >>
> >> Regards,
> >>
> >> Erik Bengtson
> >>
> >>
> >
> >
> >
> >
> >
> >
>
>
Re: classes registered in JDOImplHelper unloaded
Posted by Jörg von Frantzius <jo...@artnology.com>.
Holding strong references to class objects will also prevent any
hot-deployment mechanisms in application servers from working. Finally I
learned why it never worked for us ;)
Erik Bengtson schrieb:
> 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 these
> classes.
>
> What is the strategy to take to avoid a memory leak in JDOImplHelper?
>
> Regards,
>
> Quoting Erik Bengtson <er...@jpox.org>:
>
>
>> Hi,
>>
>> What happens if the classes registered in a JDOImplHelper are unloaded or if
>> an
>> attempt to GC the classloader?
>>
>> Later on the same class loaded by a second classloader, third, forth and so
>> on?
>>
>> Is there a memory leak here since the classloader will not be garbage collect
>> the classes as we have a strong references to the classes?
>>
>> Regards,
>>
>> Erik Bengtson
>>
>>
>
>
>
>
>
>
Re: classes registered in JDOImplHelper unloaded
Posted by Erik Bengtson <er...@jpox.org>.
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 these
classes.
What is the strategy to take to avoid a memory leak in JDOImplHelper?
Regards,
Quoting Erik Bengtson <er...@jpox.org>:
>
>
> Hi,
>
> What happens if the classes registered in a JDOImplHelper are unloaded or if
> an
> attempt to GC the classloader?
>
> Later on the same class loaded by a second classloader, third, forth and so
> on?
>
> Is there a memory leak here since the classloader will not be garbage collect
> the classes as we have a strong references to the classes?
>
> Regards,
>
> Erik Bengtson
>