To begin with, I have worked with many, many clients for whom scalability is a core concern. All of them use sticky sessions (with a backup server).
Second, Tapestry is designed to store a pretty minimal amount of information in the HttpSession, in that it tends to store simple, immutable objects rather than application-specific mutables (though that is also an option, as an Application State Object). T5 does force you to store more data between requests than T4 ... but not necessarily in the session (it also has client storage). The advantages of the redirect-after-action pattern used in Tapestry is pretty manifest. URLs are always bookmarkable. The refresh key in the browser does the right thing. The proof is, of course, in the pudding. You can debate all you want and reality has a tendency to slap you in the face. Despite the speed of the framework, I have not yet started to optimize it internally (and the new structure of T5 supports a lot of room for optimizations!). On 7/13/07, Fernando Bellas Permuy <[EMAIL PROTECTED]> wrote:
Hi, I have been evaluating several Java Web frameworks. Regarding Tapestry 5, I like very much its POJO, non-intrusive programming model. I am interested in knowing how well Tapestry 5 applications perform on a clustered environment. Like most Java Web frameworks, Tapestry 5 handles action requests in a two-step process. The first step handles the event. For actions that must show results retrieved from the database, this means that the event handling method (onXXX) must store results on @Persistent attributes in the page object. Then Tapestry redirects the browser to an URL that launches the second step (the rendering phase). In this second step, the page is dynamically generated by calling getter methods on the page object to show the results. Alternatively, the event handling method can store parameters, so that getter methods (in the second step) retrieve the results form the database. In any case, this request processing model means that most action requests store objects (@Persistent attributes) in the session. Does this model scale in a clustered environment??? It probably works well in a clustered environment that uses sticky sessions (requests directed to a given session are handled by the same machine in the cluster), but what about other clustering strategies that use mirror machines (session objects must be serialized and sent to mirror machines )???. Can Tapestry 5 be used only with the sticky session clustering model??? This model is criticized for not being fault-tolerant. Unlike Tapestry, in frameworks like Struts and JSF, the first step inserts objects in the request and *forwards* (the browser is not aware of this fact) to another "component" (typically a JSP page) to show the results. This request processing model does not use the session to store results. Is this model more scalable than the one used by Tapestry 5 on a clustered environment??? Thanks in advance! Fernando Bellas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
