Tapestry 5
  1. Tapestry 5
  2. TAP5-1197

Eliminate page pooling using shared page instances that separate their structure from the mutable state


    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.2.0
    • Fix Version/s: 5.2.0
    • Component/s: tapestry-core
    • Labels:


      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.


        Howard M. Lewis Ship made changes -
        Status In Progress [ 3 ] Closed [ 6 ]
        Fix Version/s 5.2.0 [ 12314122 ]
        Resolution Fixed [ 1 ]
        Howard M. Lewis Ship made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Howard M. Lewis Ship made changes -
        Field Original Value New Value
        Assignee Howard M. Lewis Ship [ hlship ]
        Howard M. Lewis Ship created issue -


          • Assignee:
            Howard M. Lewis Ship
            Howard M. Lewis Ship
          • Votes:
            0 Vote for this issue
            2 Start watching this issue


            • Created: