Ok - we all know that at least in classic asp using the session object was not a scalable solution.

What about in asp.net?

I've seen some claim that in asp.net session objects are now scalable and shouldn't be considered taboo anymore?

I also read some documentation from microsoft and they speak of how asp.net sessions are different in that they are:

- A reliable session-state facility that can survive IIS restarts and worker-process restarts without losing session data. 

- A scalable session-state facility that can be used in both Web farm (multicomputer) and Web garden (multiprocess) scenarios and
that enables administrators to allocate more processors to a Web application to improve its scalability. 

- A session-state facility that works with browsers that do not support HTTP cookies. 

- A throughput equivalent to that of ASP (or better) for core session-state scenarios (50/50 read/write when putting items into
shopping carts, modifying last page visited, validating credit card details, and so on). 





BUT, none of these differences seem to make session state any more scalable when running applications off of only one server.  So
using the session object would seem to be just as problematic for web applications not using a web farm?

Is viewstate state bag a viable alternative?

What about Context.Items?

Cookies instead?

Hidden form variables are a pain and I'm still unclear as to whether querystrings could/should be used with the new .net postback
architecture and still maintain viewstate??



What are the recommended solutions for storing state without significantly hurting scalability?

Any good articles on the topic?

Any advice based on experience from you guys building heavily trafficked sites???



Thx in advance,

Arthur Gaisin