.NET has addressed the whole session scalability problem by creating 3 new
scenarios.
a) Carry on as is - session managed by IIS on the same server
b) Use SQL server as the session repository
c) Use the new session manager service on the same or another server.
All three of these scenarios are invisible to the user and developer, you
simply specify how you want the framework to handle it in the app config
file.
The second and third options have been created to solve the load
balancing/web farms issue where requests are routed across multiple IIS
servers from a single session.
The session server can be a completely separate machine or just one of the
IIS machines. As it's a separate service it maintains state even if the IIS
process is stopped/re-started.
Interestingly, MS have also gone back to something that you could do in IIS3
but not IIS4/5 and that is store the session ID in the URL rather than a
cookie. Again, this is a setting in the config file.
Steve
Quote:
> I've heard that web forms are going to be so much better than web classes
> but I'm skeptical. For one thing, web forms still seem to use the session
> object to manage state. That does not scale particularly well. You could
not
> use such a method in a load balanced environment because the each request
> has to be routed to the same machine. The one that has the session object
in
> memory. Maybe I just haven't come across the correct documentation. Can
> anyone tell me if Microsoft has addressed or plans to address this
> limitation?
> jc
.net and load balancing