tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship (JIRA)" <j...@apache.org>
Subject [jira] Created: (TAP5-1197) Eliminate page pooling using shared page instances that separate their structure from the mutable state
Date Thu, 01 Jul 2010 16:49:49 GMT
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.


Mime
View raw message