Oh, a hidden gem - thanks for finding :)
Btw, this sentence misses producer methods, or are they intentionally left out? It's
not so clear for them.
LieGrue,
strub
----- Original Message -----
From: Jozef Hartinger <jharting(a)redhat.com>
To: Mark Struberg <struberg(a)yahoo.de>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
Sent: Thursday, March 8, 2012 4:47 PM
Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for @Dependent beans?
I think you are wrong. The spec says:
"Any instance of the bean injected into method parameters of a disposer
method or observer method exists to service the
method invocation only (except for observer methods of container
lifecycle events)."
So the instance should actually be destroyed immediately after the
observer method invocation finishes.
On 03/08/2012 01:47 PM, Mark Struberg wrote:
> My answer sadly is no.
>
> Dependent objects are stored in the CreationalContext which is held in the
context which holds the outer NormalScoped contextual instance.
> If the outer NormalScoped contextual instance gets desroyed, we also
properly destroy all @Dependent beans in the CreationalContext.
>
> So far so good, but now let's consider hte following scenario:
>
>
> @ApplicationScoped
> public class MyService {
>
> void doStats(@Observes RequestStatistics, UserHelper uh) {
>
>
> UserHelper is @Dependent and a new instance will get created each time
doStats() gets called.
>
> What happens is that we don't know whether the UserHelper internally
gets stored or just thrown away. In our sample most probably the later.
> Each UserHelper will get stored in the CreationalContext of our single
MyService instance. After 500.000 requests, our CreationalContext would contain
500.000 UserHelpers. Not smart, eh? This would just create a fat memory leak...
>
>
> What we can do is to store only WeakReferences. E.g. via a WeakHashmap.
This will automatically drop the entries if the instances in it get garbage
collected. But in this case are not able to invoke @PreDestroy anymore I fear,
because gone is gone ...
>
> LieGrue,
> strub
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev