How to avoid @PostConstruct on page Faces beans during postback?

Question

Hello, we're using GlassFishV2/JSAS9.1 with Mojarra 1.2_04-b22-p05 for a large project, and experiencing performance issues on form-less JSF commands when used in conjonction with @PostConstruct annotations. I feel this is an architectural issue I'm not able to resolve though, so I was wondering if anyone could shed some light on whether I'm missing something, there is some known workaround or it's a known JSF problem?
The scenario is as follows:
* Page my.jsp references Faces Beans MyFB.java
* MyFB has @PostContruct method, which execute expensive logic to initialize the data model before rendering phase
* my.jsp has a <commandLink action="#{anotherFB.myCommand}">
* anotherFB.myCommand executes some logic and nav to another.jsp
Now what seems to happen is that when we click on the commandLink, JSF does a postback to the same URL, instantiates MyFB, calls @PostConstruct on MyFB, and then instantiate anotherFB to call myCommand on it and nav to another.jsp
In this situation, the expensive @PostConstruct logic to prepare data for rendering on my.jsp is executed although it is totally useless to the use case and hurts site performance a lot.
I tried to use immediate="true" attribute, but it doesn't seem to prevent the @PostConstruct...
In the case of a JSF form commandButton on the same bean, I can see how that would be necessary, but for a commandLink to another bean, why is JSF calling @PostConstruct on the previous page beans??
I seem to be able to workaround this problem doing an if (getFacesContext().getRenderKit().getResponseStateManager().isPostback(getFacesContext()) in our @PostConstruct method and then make sure all the getters are NPE-safe, but if the commandLink is in a common include file, I'd then have to do this in every single beans within my app, which is not reasonable IMHO.
Has anyone else experienced this problem? Or even maybe worked around it somehow?
I'm curious if I'm missing something or if this is a major JSF architectural issue...
Thanks!

Answer 1

Thanks for the suggestion.
We used to do this in the past, but this yields a host of other issues including:
* no control over when getters get called and in what order
* getters can get called multiple times, so you have to implement some caching to avoid init re-execution and it can get complicated in large object models
* if a getter implements logic and blows up in the rendering phase, part of the page may have already been flushed out and you can't recover with an error page
etc.
@PostConstruct is a great standard-based option to get a bean initialized early in the JSF lifecycle, but there's just this one issue with commandLink that's problematic... :(
We're sometimes using Shale's prerender callback, which is not invoked on a postback, but I was hoping there was maybe a standard-based solution?