In a Tapestry application, the framework acts as a buffer between the application code and the Servlet API ... in particular, it manages how data is stored into the HttpSession. In fact, the framework controls when the session is first created.

This is important and powerful, because an application that runs, even just initially, without a session consumes far less resources that a stateful application. This is even more important in a clustered environment with multiple servers; any data stored into the HttpSession will have to be replicated to other servers in the cluster, which can be expensive in terms of resources (CPU time, network bandwidth, and so forth). Using less resources means better throughput and more concurrent clients, always a good thing in a web application.

Tapestry defers creation of the HttpSession until one of two things happens: When the Visit object is created, or when the first persistent page property is recorded. At this point, Tapestry will create the HttpSession and store the engine into it.

Earlier, we said that the IEngine instance is stored in the HttpSession, but this is not always the case. Tapestry maintains an object pool of IEngine instances that are used for stateless requests. An instance is checked out of the pool and used to process a single request, then checked back into the pool for reuse in a later request, by the same or different client.

For the most part, your application will be unaware of when it is stateful or stateless; statefulness just happens on its own. Ideally, at least the first, or "Home" page, should be stateless (it should be organized in such a way that the visit is not created, and no persistent state is stored). This will help speed the initial display of the application, since no processing time will be used in creating the session.