When using Sessions is bad thing, and whats wrong with it?

Question

I know that in community server <sessionState mode="Off" /> which means that you can't use Sessions, and few years ago i remember i was working on a website where we were not allowed to use sessions.
In my point of view sessions are a very helpful tool if we managed how to use the right way, but is using session variable in a website is something bad, when its bad and when its not?

Update
And What can we use instead to avoid its mess?

Answer 1

Sessions expire it is volatile so it could happen that sessions time out and such so thats a minus

Answer 2

You don't want to use sessions to store private information either. Sort of how people try to store passwords directly into cookies, which is also a no-no.

Answer 3

People are still afraid of accepting cookies, which are required to use sessions. Further, there are security issues.

Answer 4

Sessions aren't bad per se. But they should not be abused neither. You must especially avoid the "Oh, I need this piece of information here and here, let's store it in the session and reuse it later".

Instead of doing a proper OO design where information is passed around correctly in parameters, the session is used as a global unorganized storage -- which leads to potential mess.

Such global state also impedes the testability. A big unorganized session also leads to increased memory usage. An alternative to session state can be the viewstate, for instance.

(I don't know if you speak about the session state, or the whole concept of session. If it's the latter, my answer is not really appropriate)

Answer 5

One of the primary reasons why you wouldn't want to use Sessions in production environment is that the SessionID is passed via cookies (at least in JSP). And, you cannot guarantee that your client would have cookies turned on all the time. Therefore, even if you do use Session, it is recommended that you implement URL Re-writing too. As a result, the Container would use Session as well as URL Rewriting for the very first request (in order to determine if cookies are enabled). And, it would use session if the client accept cookies. Otherwise, it would turn to URL rewriting.

Note that when using URL rewriting you'll have to make sure that the response has the encoded URL. Also, if you are using Session, you'll have to take into consideration odd events like session tracking for more than one browser on the same system.

Answer 6

That's an interesting question and I agree that Sessions can be very messy if not properly used. One approach to mitigate it is to have a whole complex object (like shopiing cart content) stored in one session rather than to have multiple sessions spilled across the same web application. Sessions can actually be stored in the SQL Server database in case of let's say power outage.

Answer 7

Sometimes session state just existing kills performance. Seriously, putting a single boolean value in there can KILL your performance in some cases. Here's a specific example:

You have a dashboard page, and it hosts several little modules that each load their content via ajax. If you are using the session, you can only load one module at a time because the session is locked (per-user) during a request. If the session is not being used, there is no lock, and the browser will be able to request the maximum number of resources (4 or more concurrently).

See "Concurrent Requests and Session State" here:

http://msdn.microsoft.com/en-us/library/ms178581.aspx

If you run into this, either don't use the session, or set it to read-only (this is hard to do in ASP.NET MVC last time I checked).

Update: Two more real-world scenarios where this can happen:

• You have an asp.net page that writes images to a binary response. You do this because you need to check permissions or other conditions to determine whether and which image to serve. If you have a bunch of image tags referring to this page in their SRC to fetch images, you will only be able to get one at a time.
• You have an admin console that lets you manage tasks. You want to be able to hit a button and kick off the tasks on the server asynchronously with ajax progress bars. If your ajax calls request asp pages when you have a session (whether you refer to it or not) you will only be able to run one at a time. I guess this is similar to the dashboard example but I actually ran into this one and it killed me.