[TAP5-1197] Eliminate page pooling using shared page instances that separate their structure from the mutable state

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 5.2.0
• Fix Version/s: 5.2.0
• Component/s: tapestry-core
• Assignee: Howard Lewis Ship
• Reporter: Howard Lewis Ship
• Created: 01/Jul/10 16:47
• Updated: 08/Aug/10 23:02
• Resolved: 08/Aug/10 23:02

Description

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.