Through Tapestry release 1.0.0, an HttpSession was created on the very first request cycle, and an engine was created and stored into it.

This comes at some cost, however. Creating the session is somewhat expensive if it is not truly needed, and causes some overhead in a clustering or failover scenario. In fact, until some real server-side state is created; that is, until a persistent page property is recorded or the visit object created, it isn't really necessary to store any server-side state for a particular client.

Starting with Tapestry release 1.0.1, the framework will operate statelessly as long as possible. When triggered (by the creation of a visit, or by a persistent page property) an HttpSession will be created and the engine stored within it and the application will continue to operate pretty much as it does in Tapestry release 1.0.0.

While the application continues statelessly, the framework makes use of a pool of engine instances. This is more efficient, as it reduces the number of objects that must be created during the request cycle. However, the major reason for running statelessly is to bypass the overhead statefulness imposes on the application server.

Of course, if rendering the Home page of your application triggers the creation of the HttpSession ^[5], then nothing is gained. A well designed application will attempt to defer creation of the session so that, at least, the Home page can be displayed without creating a session.