ASP.NET Masters: What are the advantages / disadvantages of using Session variables?

Question

I've done a search on this subject already, and have found the same data over and over-- a review of the three different types of sessions. (InProc, Sql, StateServer) However, my question is of a different nature.

Specifically, what is the advantages/disadvantages of using the built in .NET session in the first place?

Here is why I am asking: A fellow .NET developer has told me to NEVER use the built in Microsoft Session. Not at all. Not even create a custom Session State Provider. His reasoning for this is the following--that if you have the Session turned on in IIS it makes all of your requests happen synchronously. He says that enabling session degrades the performance of a web server.

His solution to this is to create a session yourself-- a class that stores all values you need and is serialized in and out of the database. He advises that you store the unique ID to reference this in a cookie or a querystring variable. In our environment, using a DB to store the sessions is a requirement because all the pages we make are on web farms, and we use Oracle-- so I agree with that part.

Does using the built in Session degrade performance more than a home-built Session? Are there any security concerns with this?

So to sum it all up, what are the advantages/disadvantages?

Thanks to all who answer!

Graybill

Answer 1

First, a browser will only make two requests, to a given hostname, at a given time. For the most part these requests are for static content (JS files, CSS, etc). So, the serializing of requests to dynamic content aren't nearly the issue that one might think. Also, I think this may be confused with Classic ASP, where pages that use Session are definitely serialized, I don't believe this is the case with ASP.Net.

With ASP.Net session state (SQL mode, state server, or custom) you have an implementation that is standard, and consistent throughout an application. If you don't need to share session information this is your best bet. If you need to share information with other application environments (php, swing/java, classic asp, etc.) it may be worth considering.

Another advantage/disadvantage is that there has been a lot of developer focus on the built-in methodology for sessions with regards to performance, and design over rolling your own, even with a different provider.

Breechblock

If you could clarify on the "beyond this, the browser will only be able to make two requests to the same hostname at a given time anyhow"--even with IFrames? This peaked my interest. – Graybill

Yes.. essentially, most browsers implement the http request limit, which allows only two simultaneous requests to a given host-name. You can look here for more information. <developer.yahoo.com/performance/rules.html> – Breechblock

here's a good google search for this as well. google.com/search?q=http+two+requests+per+hostname – Breechblock

Not sure if anyone is following this question in the last couple of years. Anyways, to those listening - One of the reasons why Session state may not be recommended is because when there are multiple ajax requests to the back end, each of these requests(say PageMethods, IHttphandler) end up blocking the server as the session remains locked. Refer to this question #5118736 – Jurisprudent

@Narmatha, I believe this only happens if session state write is enabled... but worthy of noting... Another point of note is that many newer browsers have upped their per-host connections to 6, from 2. – Breechblock

Yes, this happens when the session state is write is enabled(It was too restrictive a solution for us to turn off the write completely). The per-host connections is an interesting angle to the situation. I did not delve into the depths of it thinking, the request for the connection will be queued. – Jurisprudent

Answer 2

My experience has been that the session is a good means of managing state when you use it appropriately. However, often times it's misused, causing the "never ever use the session" sentiment shared by many developers.

I and many other developers have ran into major performance issues when we mistakenly used the session to store large amounts of data from a database, so as to "save a trip." This is bad. Storing 2000 user records per session will bring the web server to its knees when more than a couple of users use the application. Session should not be used as a database cache.

Storing an integer, however, per session is perfectly acceptable. Small amounts of data representing how the current user is using your application (think shopping cart) is a good use of session state.

To me, it's really all about managing state. If done correctly, then session can be one of many good ways to manage state. It should be decided in the beginning on how to manage state though. Most often times, we've run into trouble when someone decides to just "throw something in the session".

I found this article to be really helpful when using out-of-process modes, and it contains some tips that I would have never thought of on my own. For example, rather than marking a class as serializable, storing its primitive datatype members in separate session variables, and then recreating the object can improve performance.

Bench

i completely agree with you, session is definitely not meant to act as a large data persistence medium but to be used for small chunks of data. – Guttapercha

The "state" of the session should represent all open windows a user may have, not just one. I think this should be a point to hit. – Arty

@Aaron Daniels: Completely disagree. There is no "correct" way of using sessions. If you need sessions, you're already doing something wrong (such as using stupid postbacks instead of AJAX), storing things in session instead of cookie, or blocking database IO and memory by saving the session state into it. Not to mention the NullReferenceExceptions when using the default session provider with the default timeout, with NO SessionExpiredException... – Sacks

@Quandary "blocking database IO and memory by saving the session state into it" isn't an argument against session state, it's an argument against misuse of session state. "NullReferenceExceptions when using the default session provider with the default timeout, with NO SessionExpiredException" again simply a poor implementation. – Dictatorial

@Quandary For example TinyMCE's use of sessions can not be feesably replaced with other out-of-channels methods. You wouldn't place server paths into a cookie, revealing sensitive infrastructure information to the client, nor would you encrypt this type of information because with enough time and resources they can get at the encrypted values. – Dictatorial

Answer 3

Firstly, you colleague is implementing his own DB backed session management system, I do not see what advantage this has over using built in session state stored on a database (MS SQL is the default, there is no reason not to use Oracle instead).

Is his solution better than the built in one? Unlikely. It's way more work for you for a start. Here's a simple illustration of why. Let's say you use cookies to store your ID, how do you cope with a user who turns off cookies? If you are using ASP.Net's session state there's no problem as it will fall back to using the query string. With your colleagues idea you have to roll your own.

There is a very valid question as to whether you shold have session state at all. If you can design your application not to need any session state at all you will have a much easier time scaling and testing. Obviously you may have application state which needs to live beyond a session anyway (simple case beign user names and passwords), but you have to store these data anyway regardless of whether you have session state.

Samara

Answer 4

The MS implementation of Session State is not evil in and of itself... it is how some developers use it. As mentioned above, using the built-in session state provider means that you don't have to reinvent the security, aging, and concurrency issues. Just don't start jamming lots of garbage in the session because you're too lazy to figure out a better way to manage state and page transitions. Session doesn't scale really well... if each user on your site stuffs a bunch of objects in the session, and those objects take up a tiny bit of the finite memory available to your app, you'll run into problems sooner than later as your app grows in popularity. Use session in the manner for which it was designed: a token to represent that a user is still "using" your site. When you start to venture beyond that, either because of ignorance or laziness, you're bound to get burned.

Howenstein

I disagree with "Session State is not evil in and of itself". No no, session state is evil, and the default session state provider with its default-timeout is the personification of pure evil. Who doesn't like all those pages where you spend too much time to fill the shopping cart, then go to checkout, and after searching your hyper-annoying detailed credit card details for 20 mins and 5 seconds, only to discover on return that everything is GONE. Also I like the resulting NullReferenceExceptions. Gotta love 'em. – Sacks

Answer 5

You should be judicious in your use of Session, since multiple requests to the same Session object will usually be queued: see "Concurrent requests and session state" http://msdn.microsoft.com/en-us/library/ms178581.aspx.

Note that you can set EnableSessionState to ReadOnly to allow concurrent read access to session state.

This queuing is a good thing, as it means developers can use Session without being concerned about synchronization.

I would not agree with your colleague's recommendation to "never" use Session and I certainly wouldn't consider rolling my own.

Peppergrass

Answer 6

Are there any security concerns with this?

If you roll your own you'll have to handle Session Fixation and Hijacking attacks, whereas using the built-in Session I think they are handled for you (but I could be wrong).

Bridlewise

Answer 7

the home made session as you have described is doing nothing different "SQL" state of .Net sessions and in my experience i dont think session degrades your performance in anyway. building your own session manager will require putting in several other plumbing tasks along - security, flushing it out, etc.

the advantage with in-built sessions is its easy to use with all this plumbing already been taken care of. with "SQL" mode you can persist the session data in database thus allowing you to run your app on web-farms without any issues.

we designed a b2b ecommerce app for fortune 57 company which processes over 100k transactions a day and used sessions [SQL mode] quite extensively without any problems whatsover at all.

Guttapercha

Thank you for posting! I'm trying to build an argument for using the Microsoft session and I will use this information. – Graybill

Answer 8

Correct me if I am wrong:

The primary advantage of storing Session state in a db, e.g., SQL Server, is that you are not consuming memory resources, but instead storing it to disk in a db.

The disadvantage is that you take an IO hit to retrieve this info from the database each time you need it (or maybe SQL Sever even does some magic caching of the data for you based on recently executed queries?)

In any event, this the price an IO to retrieve the session info from a db per trip to the web server seems like a safer strategy for sites that encounter a lot of traffic.

Collative