[
https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889849#action_12889849
]
Hudson commented on TAP5-1197:
------------------------------
Integrated in tapestry-5.2-freestyle #157 (See
[http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/157/])
> Eliminate page pooling using shared page instances that separate their
> structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class
> transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and
> store it via the PerThreadManager. This will be invisible to user code; the
> pages will appear to be individual instances with internal state ... but in
> fact, it will be a single instance (per locale) with all internal, mutable
> state stored elsewhere.
> Because this changes the semantics of some aspects of the component class
> transformation pipeline, there will be a compatibility mode that will allow
> pages to be pooled as with 5.1, while any third party libraries that
> contribute workers update.
> Why do all this? For large applications with very complex pages, this will
> be a big win, as Tapestry has been shown to strain the limits of available
> JVM heap (surprising to me, but apparently true) once you have a few dozen
> (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
