Tapestry is designed to be "a good citizen" of an application server that supports clustering. It's careful about what it writes into the HttpSession. The framework understands that the server that receives a request may not be the same one that rendered the page initially; this knowlege affects many code paths, and the approach Tapestry takes to caching and pooling page instances.
Your part is to properly manage the objects put into the HttpSession (via @ApplicationState or @Persist). These objects should be immutable where possible (i.e., String, or a primitive or wrapper type). For @Persist, if you change the internal state of a mutable object, you should reassign the field, to ensure that Tapestry knows to update the HttpSession (and force the value to be serialized and distributed around the cluster). Still, sticky sessions are the way to go when possible. Much more efficient use of resources ... you are scaling *out* not *up* which is always cheaper. Again, Tapestry is a good citizen, but from the application server's point of view, it's just another servlet application. The heavy lifting here is application server specific. On Mon, Sep 8, 2008 at 4:44 AM, Carl Crowder <[EMAIL PROTECTED]> wrote: > Hi all, > > Is it possible to run multiple instances of a Tapestry app on various > servers, but have them share session and application state? > > Carl > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
