[ 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.