JSPs are compiled into singleton objects. Individual JSP tags are individually pooled. Thus for a given request, a single JSP servlet will be invoked (possibly by multiple threads), but individual threads will store transient state within per-thread instances of the JSP tag objects.
Take a peek at the code generated by a typical JSP container. Eeeks! There's a lot of code in there to extract tag objects from pools, initialize them from their attributes, use them (within deeply nested try/catch blocks), then reset and return them to their pool. This is an area where Tapestry has a big performance advantage, IMHO. There's lots of opportunity for Tapestry components to cache data, especially the kind of invariant data from literal and message parameter bindings. On 6/14/06, ZedroS Schwart <[EMAIL PROTECTED]> wrote:
Just a side question about Tapestry's pooling : normal jsp pages are, as far as I understand it, pooled as well. The jsp is compiled once and then is used for all the access to this page. I don't know exactly the behaviour of jsp page when there are multiple concurrent access, so I may not spot where the poolable parf of Tapestry. Could you please provide more info ? Thanks in advance ZedroS
-- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com
