Pages are specialized versions of components. As components, they have a specification, embedded components, assets and an HTML template.

Pages do not have parameters, because they are the outermost component in the component hierarchy.

All components, however deep their nesting, have a page property that points back to the page they are ultimately embedded within. Pages have an engine property that points to the engine they are currently attached to.

Pages participate in a pooling mechanism, so that a single instance of a page component can be used by multiple sessions of the same web application. Even when a large number of client sessions are active, it is rare for more than a handful to be actively processing requests in the application server. This pooling mechanism minimizes the number of instances of a page that must exist concurrently on the server. There are some implications to this design that are discussed in the following sections.

Pages may have persistent state, properties specific to a particular user that persist between request cycles. These properties live only as long as the HttpSession. There is some complexity here, because the page state is entirely seperate from any instance of the page. Remember that on subsequent requests, a different page from the page pool may be used to service the request ... in fact, in a clustering environment, the request may be serviced by an entirely different server. Tapestry efficiently and transparently hides these details; when any portion of an application requests a page, it receives an instance of the page with all persistent page properties set the the values previously stored for the user.

In fact, any component may have persistent state, and use the page as means for recording that state.

The engine is a session persistent object. The implementation of this varies from application server to application server, but the basic idea is that the HttpSession is serialized after each request and stored in a file or database. It may then be removed from memory. When a subsequent request for the same session arrives, it is restored from the persistent storage.

In a clustering server application, consequtive requests for the same session may be serviced by different servers within the cluster. Serializing and deserializing the HttpSession is the mechanism by which the servers are kept synchronized. Persistent page properties are stored as part of the engine, and so they continue to be available, even after the engine has moved from one server to another.

The visit object is a property of the engine object, so it is serialized and de-serialized with the engine.

Pages are not session persistent. They exist only within the memory of the Java VM in which they are first created. Pages and components don't need to implement the java.io.Serializable interface; they will never be serialized.

The application engine can always instantiate a new page instance and restore its previously recorded state (the recorded state information is serialized with the engine).