When is a @Dependent scoped CDI bean destroyed, if you obtain that bean via Provider.get()?

Question

I am struggling to understand the effective lifecycle of a @Dependent scoped bean in both CDI 1.0 and CDI 1.1. My experiments so far have lead me to the following conclusions:

• A @Dependent scoped bean is not proxied.
• No @PreDestroy method is invoked when a @Dependent bean is destroyed.
• Provider.get() always creates a new instance of a @Dependent bean.
• With JBoss 6/CDI 1.0, a @Dependent bean that is created by an @ApplicationScoped bean's Provider<> field is "leaked", because it still "belongs" to the Provider.
• I have seen no evidence (yet!) of @Dependent beans being leaked by similar Providers when using WELD 2.1.2.Final/CDI 1.1. (Although this might be because these particular @Dependent beans are created by @Produces methods...!)

I see that CDI 1.1 has added a destroy() method to Instance<>, presumably to address the memory leak in CDI 1.0. But what about Provider<> - does that still leak in CDI 1.1? (And if it does, then how are you supposed to use Provider.get()?)

Basically, I have several @ApplicationScoped beans / @Singleton EJBs that I @Inject Provider fields into, and I am trying to use Provider.get() as factories for both @Dependent and @RequestScoped "helper" beans. I definitely do not want these beans to "belong" to their Provider fields, as I need the beans to be garbage collected afterwards:

public void updateStuff() {
    Helper helper = helperProvider.get();
    // use helper...
}

For my CDI 1.0 application, I was thinking of fixing the memory leak by "faking" my Providers with code like this:

provider = new Provider<MyBean>() {
    @Override
    public MyBean get() {
        return getReferenceFor(MyBean.class);
    }
};

private <T> T getReferenceFor(Class<T> type) {
    Bean<?> bean = beanManager.resolve(beanManager.getBeans(type));
    CreationalContext<?> context = beanManager.createCreationalContext(bean);
    try {
        return (T) beanManager.getReference(bean, bean.getBeanClass(), context);
    } finally {
        // Destroy this context - which I don't want to exist anyway.
        // I only need a strong reference to a fully @Inject-ed bean!
        context.release();
    }
}

MyBean is a @Dependent scoped bean with no @PreDestroy method that only needs to be garbage collected when I've finished with it. However, I can't find a lot of information about Providers, and so can't tell if I'm arming some kind of time-bomb by doing this.

Some of my @Dependent scoped beans (which I still obtain via Provider.get(), btw) are created by @Produces methods. Are they still in danger of being leaked?

Can anyone advise me, please?
Thanks,
Chris

Zamia

I have also had this issue. I verified in JVisualVM that all Dependent beans from my ApplicationScoped bean never get garbage collected because they are dependent on the ApplicationScoped bean. I ended up doing a similar thing as you did. CDI 1.1 fixes this to an extent with the CDI class as Martin said, but I'm on 1.0 in EE6, so I had to use the BeanManager. – Zoroaster

Answer 1

From Weld docs on lifecycle of @Dependent beans:

An instance of a dependent bean is never shared between different clients or different injection points. It is strictly a dependent object of some other object. It is instantiated when the object it belongs to is created, and destroyed when the object it belongs to is destroyed.

So injection of @Dependent object won't introduce a leak on its own, there's simply nothing to fix. Creating a short-lived context just "to be on the safe side" is totally unnecessary because dependent beans aren't tied to a context. As far as CDI is concerned after being injected they are ordinary (strongly reachable) Java objects.
If you need instantiation logic put it in a producer method and that's it.

Rosendorosene

Thanks for the reply. My particular @Dependent beans are transient "worker" beans rather than object fields. For example, one of my EJBs has a function that does something like: void updateStuff() { Helper helper = helperProvider.get(); // use helper ... } This approach allows the helper to have assorted cDI goodness injected into it, such as an EntityManager etc. However, I was unaware that I was leaking the Helper object afterwards! – Zamia

BTW, according to the CDI documentation: "An instance of a bean with scope @Dependent obtained by direct invocation of an Instance is a dependent object of the instance of Instance." So it's slightly more than an "ordinary strongly reachable Java object" - it's bound to its creator! It is this binding that I am trying to undo with my workaround code. – Zamia

Simply put that portion of the doc says "No matter how and where you inject it @Dependent is a dependent object of the injection point". So unless an owner of the injection point is leaked it'll be fine. On the side note, delegating from an EJB bean to a CDI bean is a bit strange; usually it's the other way round. Wouldn't a stateless EJB be more suitable than a @dependent in this case? – Rosendorosene

My Provider is a field on an @Singleton EJB, and so the injection point never goes out of scope. Hence the leak. And I'm delegating from EJB to a CDI bean because a @Dependent CDI bean is just a POJO; I only need a light-weight, transient "helper" object. Besides, I've seen other memory leaks with JBoss 6.1.0 and stateless EJBs because JBoss seems to constantly allocate new ones without reusing the old ones unless you configure them with a "strict max pool". – Zamia

Answer 2

I haven't tested your construct, but me personally, whenever I need to go lookup a bean programmatically, I prefer CDI.current().select().get(). Using this construct, I can confirm that you will get a new @Dependent bean for each lookup. It is not tied to the provider (the CDI container in this case).

See this and this. What we have here is an Arquillian test setup that deploy a Servlet to a "real" (or "remote" using Arquillian terminology) server and issues HTTP GET request to find out what beans are produced on the inside.

The outcome is that both GlassFish 4.1 and WildFly 8.2.0 will provide the client code with one new @Dependent bean on each lookup and if I have understood your question correctly, then that is exactly what you want. Hope it helps!

Aldis

I had a similar case, using CDI.current().select().get(), but with jprofiler, I still see @dependent instance tied to CreationalContext, and so not destroyed. Any advice? – Buonaparte