Session as Static Object Storage

By coming late to the game with Classic ASP, I get to understand the why of ASP.NET evolution. It revolves around scalability. We have a page on a browser. When the user interacts with that page, the first available processor in the farm should be able to deal with it. But a processor has its own memory and that is where Classic ASP chose to store its Session objects.

Big problem! The concept of Session scope is fine. A session exists from the point a user logs on until that user is logged off. They may not elect to log off, it might be done for them automatically with a time out. The issue lies in that many different web pages may be viewed during that Session.

So instead of creating stateful web pages, it is elected to implement state as an adjunct to Session. Information that persists as long as Session is in progress and like a bubble bursting, being gone when the Session ends.

This only became a problem when someone realized that a single server could not possibly handle all the traffic coming in from a really BIG pipe. So where it was good enough to store the Session Objects on a single server for light traffic, when the server got swamped it was an effort to move that same traffic unto other servers.

Long story short, Classic ASP does NOT share Session objects the same way ASP.NET does (run your page on any server in the farm) and so one must rework code and work around the Classic code with one of several solutions that allow the old and new ASP to communicate.