cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject RE: Evaluation of Cocoon
Date Mon, 02 Feb 2004 18:22:09 GMT
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.


-----Original Message-----
From: Brent L Johnson []
Sent: Monday, February 02, 2004 10:15 AM
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

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:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message