myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Date Sun, 24 Nov 2013 18:37:15 GMT
Hi Thomas

2013/11/23 Thomas Andraschko <andraschko.thomas@gmail.com>

> Hi Leo,
>
> all advantages and disadvantages are 100% fine for me but i don't like
> this one:
>
>
> - Third party libraries needs to be compatible with the technique.
>
> What changes are required for third party components?
>

It is something trivial. By default all the code in UIComponentBase is
already in place, so if all components extend from UIComponentBase
everything will work just fine. In some special cases where there are
components which variables outside StateHelper we need to add the ability
to do a hard/soft reset. For example this is the code that will be on UIData

    public Object saveState(FacesContext context)
    {
        if (context.getViewRoot() != null)
        {
            if (context.getViewRoot().getResetSaveStateMode() ==
RESET_MODE_SOFT)
            {
                _dataModelMap.clear();
                _isValidChilds=true;
                _rowTransientStates.clear();
            }
            if (context.getViewRoot().getResetSaveStateMode() ==
RESET_MODE_HARD)
            {
                _dataModelMap.clear();
                _isValidChilds=true;
                _rowTransientStates.clear();
                _rowStates.clear();
                _rowDeltaStates.clear();
            }
        }
        /*** continue with state saving ***/
        /*** ...... ***/
    }

Basically the idea is reinitialize the state of the component to a state
like it is being created by first time.



> Would it be possible that components are still 100% compatible with
> mojarra without changes?
>
>
Of course, since the idea is just check for an attribute in UIViewRoot
called "oam.view.resourceDependencyUniqueId" when saveState(...) is called
for a component, if the attribute is not set, nothing will happen and
things will work as usual.

Note the basic idea behind this technique is take advantage of the partial
state saving algorithm and use it to check if a view can be reused or not,
but in some special cases like UIData, not all information related to the
component state is stored in StateHelper. That's the reason why the
detection technique is not 100% fail safe.

regards,

Leonardo Uribe


> Regards,
> Thomas
>
>
>
> 2013/11/23 Leonardo Uribe <lu4242@gmail.com>
>
>> 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>
>>
>> ____________________________
>>
>
>

Mime
View raw message