[
https://issues.apache.org/jira/browse/TRINIDAD-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Sullivan resolved TRINIDAD-1899.
--------------------------------------
Resolution: Fixed
Resolved in revision 992031 on main
Resolved in revision 992030 on 1.2.x
> SessionChangeManager performance and behavior improvements
> ----------------------------------------------------------
>
> Key: TRINIDAD-1899
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1899
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 1.2.14-core , 2.0.0.3-core
> Reporter: Blake Sullivan
> Assignee: Blake Sullivan
> Attachments: trin_1899_1_2_x.diff, trin_1899_main.diff
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Currently the SessionChangeManager when working with JSPs maintains a single
> list of changes to be applied and applies them in order. While the list does
> support collapsing attribute changes even across component moves, this
> approach has some performance limitations in and of itself and decreases our
> ability to make other performance improvements:
> 1) Because some changes affect multiple components, we wait to the end of the
> document tag to apply the changes (so that all components exist).
> Unfortunately this means that when the tags are executing, they don't
> actually have any values that were modified by a change available to them.
> This prevents us from applying optimizations where we don't even execute the
> tags that are subtrees that won't be visited by the lifecycle (for example
> undisclosed tabs).
> 2) Because the changes are not applied at the time of tag execution, we need
> to do a separate findComponent() for each change that we want to apply. This
> can get expensive for large numbers of changes.
> The solution is to group changes into
> 1) Changes that apply to a single component
> a) Collapsible single changes
> 2) Cross component changes
> a) Cross component changes that can change the identity of a component
> 1) Changes that are applied to a single component are saved under the
> component's original scoped identifier. The collapsible changes are
> collapsed.
> 2) Cross component changes are maintained in a single page wide list
> 3) Cross component changes that change the identify of a component update a
> mapping from the new (current scoped identifier) for the component to the
> original scoped identifier so that as new changes are applied, they are
> applied to the correct entry in 1)
> 4) For efficiency, the serialized form of the changes is a single list of
> changes with all collapsible entries collapsed, even across changes that
> change the identity. The rename maps and a single component changes can be
> rebuilt on demand from this list.
> The upshot of these changes are that:
> 1) We can apply all of the single component changes to a component at tag
> execution time, even if that component had a change that moved it. This
> opens up optimizations where we don't execute child tags
> 2) Since all collapsible changes, like attribute changes are collapsed, we
> have fewer changes to apply
> 3) Only the rare, cross-component changes need to be applied using separate
> findComponent calls
> To apply the changes at tag execution time, we need a new api on
> ChangeManager:
> /**
> * Apply non-cross-component changes to a component in its original
> location. This is typically
> * only called by tags that need to ensure that a newly created component
> instance is
> * as up-to-date as possible.
> * @param context
> * @param component Component to apply the simple changes to
> */
> public void applySimpleComponentChanges(FacesContext context, UIComponent
> component)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
