This is generally a problem when you are writing applications to run on the internet, but is often not relevant for an internal application running over an intranet.

When you have a large web-site that consists of more than one web server, you have the following problem - if you use a load-balancing router to spread incoming HTTP requests around to different web servers, then you need to think carefully about keeping information specific to a particular client in the memory of any particular webserver.

If you chose to keep client-specific information in memory, then you need to configure your router such that all HTTP requests from that client got to the same web server. This is called ServerAffinity. It's not something you want to do for a lot of reasons.

For instance, some routers only allow you to pick the destination server based on information in the TCP header - such as the TCP address of the client machine. This would be fine, except that many ISPs (like AOL) make it seem that ALL of their customers' packets come from a small number of proxy machines. So in the worst case, you would pin ''all'' AOL requests to a single machine - which defeats the purpose of load balancing.

Another significant problem is lack of failover in this configuration. If you keep client-specific data in memory in an app server, and then that app server crashes, then all of the clients "pinned" to that app server are hosed.

So, the alternative (not keeping data resident in memory on the web server) is the generally accepted solution. Other solutions exist (like distributed session state) but it's usually easier to avoid the problem.

-- KyleBrown
----
The above says that you want to avoid server affinity for "lots" of reasons, but I only see one reason. What are the others? ''I can think of one - performance and scalabilty may be reduced by the router.''

----
JServ from Java Apache project implements load balancing on the WebServer-to- ServletServer connection layer. Servlet sessions are preserved this way. It is very hard sometimes to implement completely stateless web application (i.e. not to use session facilities of the servlet) just because the amount of data going back and forth between client and server in the form of hidden <INPUT>'s sometimes becomes enormous and hard to maintain all over the HTML content.

-- DanielSadolevsky

----

WebSphere also implements HTTPSession sharing (e.g. distributed session state) in the same way. However, the question is how scaleable is the solution? We at IBM will admit readily that the way we did it in version 2.0 of the product wouldn't scale up beyond a few tens of servers. Therefore we rewrote that part of the product for the upcoming version 3.0. However, even the updated version may not scale to HUNDREDS of servers (whether it does or not is still an open question). Thus the whole question of avoiding server affinity comes back again...

The question is which is more important to your particular application - scaleability or ease of programming? How can we minimize the impact of either?

One more thing - you said: "the amount of data going back and forth between client and server in the form of hidden <INPUT>'s sometimes becomes enormous and hard to maintain all over the HTML content."

I will agree that it can become enormous. The data transfer alone can be an Achilles heel to this kind of solution. However, your other problem (maintenance over HTML content) can be solved by strict application of SeparateStaticContentFromDynamicContent.

-- KyleBrown