You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by bu...@apache.org on 2004/06/02 14:45:16 UTC

DO NOT REPLY [Bug 29340] New: - Suggest to use component level pooling instead of page level pooling

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29340>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29340

Suggest to use component level pooling instead of page level pooling

           Summary: Suggest to use component level pooling instead of page
                    level pooling
           Product: Tapestry
           Version: 3.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Framework
        AssignedTo: tapestry-dev@jakarta.apache.org
        ReportedBy: yjshen@yahoo.com


As I understand, tapestry currently using page level pooling and isolating 
mechanism to approach concurrent access. But this has a disadvantage as 
described below:

Suppose page1 declared component1, ..., componentN enclosed respectively in 
block1, ..., blockN in the page template. Now user1 request page1, depends on 
his session state, this request may only use component1 in this page. And 
simultaneously user2 request page1, and only use component2 depends on his 
session state. Now each component in page1 will have 2 instances although the 
max concurrent actual use of each component is 1. This may result an in-
efficient use of memory for pages contains many such components when there is 
a high concurrent access to this page.

If the page level pooling and isolating is broken down to component level, 
component instance will not bind to page instance, thus can use memory more 
efficiently, and also may be fast to instantiate a new page in case of page 
instance used up, because it can use some existing component instances in the 
pool to composite the new page instance to satisfy current request.

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org