Details
-
Bug
-
Status: Resolved
-
Resolution: Incomplete
-
3.0
-
None
-
None
-
Operating System: All
Platform: All
-
29340
Description
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.