Should PARTIAL_STATE_SAVING be set to false?
It seems that today (April 2012), both MyFaces and Mojarra's JSF 2.1 implementations have defects around partial state saving and that PARTIAL_STATE_SAVING should be set to false.
Is this true?
Answer
Should PARTIAL_STATE_SAVING be set to false?
Only when you encounter a general defect related to partial state saving in your webapp which can really not be solved/workarounded the other way. Partial state saving has namely major advantages as to overall performance and memory usage. See also Why JSF saves the state of UI components on server?
I can't 100% reliably speak for MyFaces, but in Mojarra the root cause of problems around partial state saving will manifest when you're binding any attribute of a tag handler (tag handlers are recognizeable by the lack of the rendered attribute on the tag such as JSTL tags) to a view scoped bean, or when you're binding the id or binding attribute of a JSF component to a view scoped bean (those attributes are namely resolved during building/restoring the view).
This problem is caused by a chicken-egg issue as described in JSF issue 1492 and JSF spec issue 787: with partial state saving enabled, the view scoped beans were stored in the partial view state. So to extract view scoped beans, the partial view state has to be restored. During restoring (building) the view, the EL in all of the aforementioned attributes will be evaluated. However, since there's no view scoped bean instance available at that moment, a brand new one instance will be created. This will however have all its properties set to default! After restoring the view and getting the original view scoped beans back, they will be put back in the view scope, overridding the (temporary) instances created during restoring the view. But the EL expressions of those attributes are already been evaluated based on a completely different instance and can't be restored.
This chicken-egg issue is solved since Mojarra 2.1.18 and 2.2.0 by storing view scoped beans in session. If you can't upgrade for some reason, then this can indeed be solved by disabling the partial state saving by setting javax.faces.PARTIAL_STATE_SAVING to false. An alternative is to just not bind the aforementioned attributes to a view scoped bean at all, but look for an alternative solution.
You could also set the javax.faces.FULL_STATE_SAVING_VIEW_IDS instead. This allows you to specify a comma separated list of all view IDs for which partial state saving needs to be turned off:
<context-param>
<param-name>javax.faces.FULL_STATE_SAVING_VIEW_IDS</param-name>
<param-value>/some.xhtml,/other.xhtml</param-value>
</context-param>
This allows you to benefit from partial state saving as much as possible and turn it off for only a subset of views on which the partial state saving related problems can really not be fixed.