JSF 2.1 ViewScopedBean @PreDestroy method is not called

Question

I have a method in a view Scoped Bean with the @PreDestroy annotation and another one with the @PostConstruct annotation.

The @PostConstruct method is properly called every time I navigate to the page that uses this view scoped bean.

However, when I navigate to a new page (which doesn't use this view scope bean) by <h:link/>, the @PreDestroy method is never called.

I am not talking about changing manually the url or the end of the session, just of a navigation case.

What I am missing?

Thanks in advance

Answer 1

This is by design. It will only be destoyed immediately when a POST action results in a navigation which isn't a postback to the same view (i.e. the action method didn't return null or void, but a fullworthy String, even when just empty).

The <h:link> generates a GET link which doesn't invoke any POST action. As it's not reliably possible to notify the server side by a (XML)HTTP request when the view is unloaded, JSF can't be notified to destroy the view scoped bean associated with the view. In such case, the view scoped bean will then only be destroyed when the session expires or when the max logical views in session has exceeded (the default is 15) and the associated view is the first in order.

If you really want to destoy the view scoped bean by a navigaiton action, then your best bet is to make it a POST request by <h:commandLink> instead and issue a redirect by returning the navigation outcome with ?faces-redirect=true parameter. But this is after all not SEO friendly as bots won't index POST links.

I would after all not care about the view still being in the session. If you intend to do some cleanup or logging, I'd look for alternative ways, depending on the concrete functional requirement.

In theory it would be possible by HTML DOM onbeforeunload event, but this is a non-standard event and the browser behaviour is unspecified as to what happens when you send an ajax request during that event. It will sometimes arrive, but sometimes also not.

Update: in practice, this has been implemented in OmniFaces @ViewScoped since OmniFaces 2.2. Initially with help of synchronous XHR and since OmniFaces 2.6 with help of beacon. It's working quite well in major browsers. Since OmniFaces 2.3 it even immediately destroys the associated JSF server side view state, and since OmniFaces 2.6 it even immediately destroys the physical beans, hereby further reducing unnecessary memory usage. See also among others JSF: Mojarra vs. OmniFaces @ViewScoped: @PreDestroy called but bean can't be garbage collected

Answer 2

I have prepared a small NetBeans project demonstrating when JSF2.2 CDI-compatible @ViewScoped beans (javax.faces.view.ViewScoped) are released for garbage collection under different navigation cases (for Mojarra 2.2.9, Glassfish4, NetBeans8.0.2, JDK1.7), available for download here. The code is omitted here, please see that download.

The navigation cases handled and the results are summarised by this image:

To monitor the @ViewScoped beans, use VisualVM against Glassfish (or the in-built NetBeans profiler on the mini project) and filter the Sampler memory Heap histogram class view on the package name 'webel.com.jsf'. The following image shows an absurd 66 instances of webel.com.jsf.Jsf22ViewBean after copious experimenting with h:link, browser URL GETs, and browser RELOAD GETs, which instances will not be garbage collected (which you can test using the VisualVM Perform GC button):

By comparison, navigating away from the index.xhtml (which uses the @ViewScoped bean once for a simple EL variable read) to done.xhtml (which does not use the bean at all) using h:commandButton and an action method expression or an action string results in the @ViewScoped bean being released for garbage collection (there is always one reference from the WeldClientProxy to a @ViewScoped bean, and as you navigate back and forth using h:commandButton the WeldClientProxy moves from one releasable bean to the next).