You are under a slight misperception. In a clustered environment all requests must go to the cluster, but to any server in the cluster - not just the one the user logged into. Cocoon needs to make sure that it either a) stores what it needs in the session so that the session can be replicated b) always handles null values by reloading the correct data.
My understanding is that if you use flow with continuations, this is a non-trivial situation. A totally stateless app doesn't need them, and so should be able to use any type of load-balancing (e.g., dns round-robin).
Geoff
-----Original Message----- From: Brent L Johnson [mailto:[EMAIL PROTECTED] Sent: Monday, February 02, 2004 10:15 AM To: [EMAIL PROTECTED] Subject: RE: Evaluation of Cocoon
Subsequent requests may be routed to different servers. Here I see a possible problem with Cocoon
The same problem will apply to any site that uses sessions.
Yes, though most application servers have some mechanism for replicating sessions. Having 'sticky' sessions is certainly a good idea for performance reasons, but if one machine goes down in such a setup no one is affected.
Umm.. someone can correct me if I'm wrong. But I believe things like sticky sessions and session replication have nothing to do with Cocoon. This all depends on the servlet container you're using to serve up cocoon correct?
Also - at least from my experience with the terminology "sticky" sessions.. this usually has to do with a load balancer and sending requests to one particular machine. I.e. user1 connects to the website on server2 and gets a session.. from then on that session's requests are all processed by the same server (server2) until the session expires.
So - I may be wrong, but I think most of these requirements that you have are probably not dependent on Cocoon itself but your infrastructure and servlet container.
Anyways, in our case the servers are located at different sites, and the application is completely stateless.
Well.. I dont think this should affect Cocoon anymore than any other Servlet/JSP web development.
- Brent
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
