Question

Lets say I have a managed bean called A that is @RequestScoped Let’s say A has a reference to another managed bean B and B is declared to be @SessionScoped. Will the fact that A has a reference to another bean with longer scope prevent A from getting garbage collected at the end of the HttpRequest?

Will the situation change the other way around ie if B contains a reference to A? if yes then why ?

Answer 1

Will the fact that A has a reference to another bean with longer scope prevent A from getting garbage collected at the end of the HttpRequest?

No, an object instance is only eligible for GC if there are no references to it anymore.

A request scoped bean is by default only referenced in the current HTTP request (as a request attribute). So if the HTTP request is finished and get destroyed, then the request scoped bean becomes completely dereferenced and is thus eligible for GC. That the request scoped bean in turn contains a reference to a session scoped bean is totally irrelevant to the GC. Only when the session scoped bean is not referenced anywhere (i.e. when the session has expired, for example), then the session scoped bean becomes in turn also eliglible for GC.

---

Will the situation change the other way around ie if B contains a reference to A? if yes then why ?

Yes, it will change. A session scoped bean is by default only referenced in the HTTP session (as a session attribute), which lives longer than the HTTP request. So the request scoped bean will live as long as the established HTTP session. This will cause potential data integrity problems because you’re referencing something which supposedly shouldn’t live that long. That’s one of the reasons why JSF doesn’t allow you injecting a narrower scoped bean in a wider scoped bean by @ManagedProperty.

All with all, the managed bean scope shouldn’t be chosen based on GC behavior, but on the data it holds. See also How to choose the right bean scope?