Hi Some time ago it was discussed under these topics:
[core][proposal] JSF View Pooling (going beyond JSF Stateless Mode) http://markmail.org/message/54rb3aphc6txwzbr [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces? http://markmail.org/message/pc42cbcvvhlboivb The advantages and disadvantages of include view pooling into MyFaces. With the recent work done in: https://issues.apache.org/jira/browse/MYFACES-3825 And other tests done, some assumptions over this topic have changed. For example: Before: - The use ui:param uses EL VariableResolver, makes the view non poolable, because the ValueExpression instances are not stateless in this case. After: EL expressions under "alwaysRecompile" mode can be cacheable and it was verified that no information related to the state is included into EL expressions, so if two component trees were created by the same facelet under the same conditions, they will have both the same EL expressions. Before: - It is difficult to keep the code synchronized between versions of JSF, because each concept related to view handling affects how the view pool works. After: Now is the right time to include it, because we are now in JSF 2.2, and all new features should go there. Before: - It could create memory fragmentation, making garbage collection slower. - Higher memory footprint. After: The view pool holds the views using a soft reference, so the garbage collector will be able to collect the views at any time. There is no need to worry about memory fragmentation. The increase of memory use due to the view pool is not significant compared with the savings of memory usage in general. Before: - Detection technique to enable this optimization is not 100% fail-safe. After: It is still true, because some components needs to be compatible with the technique, but with MYFACES-3825 if all components in a view are compatible we can be sure that the view is poolable. The current disadvantage list is this: - Detection technique to enable this optimization is not 100% fail-safe. - Third party libraries needs to be compatible with the technique. - Complexity can be too high, (but we can reduce the burden doing some proper documentation). Do the advantages justify the introduction of this concept? In my personal opinion probably yes by two main reasons: - It improves significantly the time spent in ajax request. - If all components in a view are compatible, that view is poolable. Should we include it in MyFaces 2.2.x? why not? after all, it is something that can be optional. For example, libraries like Trinidad provides org.apache.myfaces.trinidad. CACHE_VIEW_ROOT web config param. This feature is something that aims to the same and it is even better. I think it is worth to give another round to this topic and see what happens. regards, Leonardo Uribe http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces ___________________________ Don't miss it: CONFESS_2014@ JavaLand 2014 <http://www.javaland.eu/en/javaland-2014.html> ____________________________
