Quite true. Of course the best solution is not to maintain state at all. Sure, sending all the information in hidden fields can be a pain, and using the URL to send the info looks a little ugly, but for the best performance, IMNSHO, it's the only way to go.
>I also understand that IIS does not scale objects across multiple IIS servers, is that correct? If so...and you have a 3-server IIS farm, if someone comes in on server 2 and creates an object (or just a simple session variable), their next connection to the IIS farm could be on server 1...where the object doesn't already exist?
>
>Yet another reason to maintain states with a database or something like that.
>
>-Joe
>
>
>>It's primarily a scalability thing. Always remember that the Session object and the variables and objects it contain are stored on the web server. This means that for every user, you could have one of those objects instantianted. Multiply the resources used by that object by the number of users and the resource usage on the server can skyrocket. Add more objects and it gets even worse. We rarely store anything to the session object for that reason. Sure it's convenient, but if a site starts to get heavy traffic, it can cause you serious grief.
"It is an important and popular fact that things are not always what they seem. For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much -- the wheel, New York, wars and so on -- whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man -- for precisely the same reasons." - Douglas Adams
