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