Jim, You still have some different options to pursue in a cluster..
- "sticky" sessions, so that requests of the same user will go to the same server in the cluster. Good for load balancing, but if a server fails, the users of that server will loose their session. - session replication in the cluster - this seems to be the approach you are thinking of. Here I would indeed imagine that the amount of data you store in the session heavily influences performance. - persist the session. Could be in clustered rdbms, could be one of these distributed key-value stores that are all the rage these days, like Cassandra or HBase. Maybe you could let us know what you ended up doing, once you've finished your project. Good luck, Lutz On Wed, Jan 6, 2010 at 4:37 PM, Jim O'Callaghan <jc1000...@yahoo.co.uk> wrote: > Lutz, > > You raise some very interesting points. I've replied to some of the other > posters regarding the reasons I was trying to minimise session use, though > taking their replies on board and your own email I think the best course of > action is to proceed with using the session state and just minimising the > amount of data held. Thanks for your contributions. > > Regards, > Jim. -- altocon GmbH http://www.altocon.de/ Software Development, Consulting Hamburg, Germany --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
