What's the problem with Sessions in ASP .Net

Question

I keep hearing that it's bad practise to store large object collections / anything in the session. Often during conversation it's quickly followed by: 'Just turn sessions off'

So what is the general problem with sessions? I use them a fair bit and since they 'real' session is stored behind a strongly typed container I don't really see the issue.

Answer 1

This is an old thread although. But I have an experience for a session problem. I would like to share it.

There is a simple flow.

1. One .aspx validate a client, and read a bill-html from a file (for this client), then save this html(about 2MB) in a session variable.

2. This .aspx will auto redirect to next .aspx, the next .aspx retrieves this html from session. Then show it to the client.

It works fine in most cases. But some clients encountered a problem: The bill he saw is not his bill, but others.

We used sniffers tools to intercept the network package. And we saw a strange situation: Our IIS has definitely sent the SessionID(eg: 1111111) to the client, But when the client redirects to next page and tries to access session. The SessionID(eg: 11112222) that this client brings is different.

We think that the browser of that client does not accept the SessionID. And finally, we abandon the use of Session, and solved this problem.

Answer 2

You may want to check out this question as well.

Answer 3

Here's my take -- sessions are not bad but sometimes they are overused. It can also be harder to understand a web application's flow when it relies on a lot of sessions so of course you should be careful not to get carried away.

However, you should feel free to use them anytime you need to store temporary data to be made accessible across multiple pages. In no other situation should they be used. But that situation is one for which sessions were specifically designed.

Now, if you're worried about memory consumption on the server, that's not necessarily a reason to avoid sessions. But it may be more of a reason to avoid the InProc session provider. In fact I'm not a fan of InProc sessions as they tend to expire prematurely after a certain number of recompiles in your application.

What I actually prefer and nearly always use are SQL Server sessions. They'll be slightly slower, but the benefits are numerous. They'll persist even if the server is rebooted and that makes them a very reliable choice. And of course since they're stored in the SQL file system instead of in memory, they won't make such a big hit on memory.

This article on MSDN talks about the various session providers and also explains how to configure SQL to handle your sessions. If you don't have SQL, just know that even the free SQL Server Express 2008 can be configured as your session provider.

Answer 4

There is a huge difference between storing BIG objects and small objects in a session

The session will stay alive on a server untill it expiers, and that means those big objects pollute your available memory. If you do that with a server under load, or a server that runs many application pools, then this can cause trouble.

You dont need cookies to have a session, since ASP cal also encode that information in the urls. Also you can configure the session store to run out of process, or even to store the information inside a SQL Server (reducing the memory load on the server, and enabeling sessions across a farm)

So basically: Objects are ok - Big objects not

Answer 5

2 major issues come to mind... 1) Persistence of sessions across servers when you start scaling your website 2) Memory usage explosion from storing UI objects in session state

The more serious issue is the tendency to store objects in session. When you store something as innocuous as a Label from a page on your page, you get LOTS of unwanted object attributes as well. You probably just wanted the text of that label stored in your session, but along with it, you get references to the page itself...and all of a sudden, you have a massive usage of memory to store the page, its view state, and lots of unwanted attributes in memory on your server.

Check out this link about storing UI elements in session

Answer 6

There are two things to be careful of:

1. Memory consumption: if you store large data objects in session and you have many user you may well run out of memory or at the very least triggering many early recycling of your application
2. This is only a problem if you have multiple web servers (web farm): the session has to be stored externally (not in process) in a SQL server or a windows service so that it is accessible from different machines. This can be quite slow at times.

Answer 7

There is nothing wrong with session - you just need to be mindful of its limitations. To say "just turn off session" is throwing the baby out with the bathwater.

Answer 8

Storing large objects in Session is bad, yes, but "large" is relative.

Basically, storing an object in session will keep it in memory until the session expires, so if you have a site with a high user count all storing mega-objects in their session, you'll kill your server pretty quickly.

With that being said, an argument could be made for the idea that if you have objects that are 5k+ in memory and have enough users to actually cap out a server then you can probably afford more hardware anyway.

There are also topics like server clustering and session integrity between boxes in the cluster. Some frameworks handle this, I don't know if .NET does or not.

Answer 9

1. Session requires the user to have cookies turned on
2. If you're working in a web farm, you'll run into trouble.

I guess these reasons don't have anything to do with storing large objects in session, just in using sessions at all.

Answer 10

I had thought that it largely depends on the traffic to your web site. If you are running something like amazon.com, trying to store the user's shopping cart in a session would take huge amounts of IIS allocated memory, bringing down your web server. For smaller web sites, session variables are fine to use in moderation.