[
https://issues.apache.org/jira/browse/MYFACES-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842260#comment-13842260
]
Thomas Andraschko commented on MYFACES-3664:
--------------------------------------------
thanks for your effort Leo.
Will you also do another performance/memory/troughput comparison after 2.2
release? Would be great!
> JSF View Pooling (going beyond JSF Stateless Mode)
> --------------------------------------------------
>
> Key: MYFACES-3664
> URL: https://issues.apache.org/jira/browse/MYFACES-3664
> Project: MyFaces Core
> Issue Type: New Feature
> Components: JSR-344
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
> Attachments: myfacesStatelessMode-12-view-pool.patch,
> myfacesStatelessMode-6-view-pool.patch, myfacesStatelessMode-8-view-pool.patch
>
>
> In the last months, I have been doing some investigations around "stateless
> JSF" ideas. The intention is try to find ways to improve MyFaces Core
> performance as much as possible, without lose all those nice features we all
> are used to.
> In summary, the justification around stateless JSF is that, if it is possible
> to cut the build view time from a request, there will be an improvement from
> both speed and memory perspective. This is true, but only to some point,
> because the response time for a request is given by the build view,
> validation/invoke application and render response time.
> To get to the same goal, without sacrifice JSF stateful behavior, other
> improvements has been already done (cache EL expressions, cache ids, make
> tree structure lighter, ...). The idea is cache that "stateless information"
> into a place where it can be reused effectively, which in this case is inside
> Facelet abstract syntax tree (AST). This has worked well so far. The side
> effects of enable these optimizations has been analysed, and there is a good
> understanding about this.
> In few words, the basic idea about stateless JSF as proposed originally by
> Rudi Simic in his blog is this:
> Mark the view as stateless using some attribute.
> Use a pool of views, because views are not thread safe.
> Before store the view in the pool, use a visitTree call to reset the fields.
> Unfortunately, it was quickly found that the implementation proposed requires
> a better view pool and try to reset the fields is not fail-safe, because the
> component tree also stores more than just the input field values.
> Additionally, it doesn't provide a way to use it for dynamic views.
> Provide a thread safe implementation of UIComponent that can be reused across
> threads is not a good solution, because anyway there is some information
> that is inside UIComponent and should be stored per thread, and precisely
> UIComponent is a place specifically designed to store that information.
> Based on the previous background, the big question is if a solution based on
> object pooling pattern can be done effectively for a web framework like JSF.
> A good description of the technique and its trade-off can be found at:
> http://en.wikipedia.org/wiki/Object_pool_pattern
> In few words, the proposal is go "Beyond JSF Stateless Mode", and instead
> blame the state, make it your friend. Let's just take advantage of the
> stateful nature of JSF to allow reuse views fully or partially.
> How?
> - PSS algorithm can be used to check if a view has been modified or not,
> checking its state. So, it can be used to check which components has state,
> and if it is possible to provide a way to reset the state of a component to
> the initial state set by the first markInitialState(), restore the state is
> possible.
> -If the view cannot be reset fully, it is possible to use facelets refreshing
> algorithm and reuse a view partially.
> - Add some additional code to recover a view instance when it is discarded,
> and store it into the view pool. This requires some changes over
> NavigationHandlerImpl, because it is not possible to reuse a view and store
> it in the pool that is still on usage, so it is necessary to do a "deferred
> navigation", changing the default ActionListenerImpl and ensure
> handleNavigation() is called before end invoke application phase but outside
> the visitTree() call.
> - In MyFaces there exists the concept of FaceletState. It is possible to use
> this concept and cache even dynamic views, because each different
> FaceletState can identify an specific view structure.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
