Sessions are the Achilles heel of a Web application

Michel T. Nygard wrote the following in his book Release It!: "Sessions are the Achilles heel of a Web application."

I have seen several developers including myself using Session a lot. Session is a wonderful way to keep stuff cached per user in a Web application. But I get scared when I see developers putting large search result into a Session or adding everything from a tiny byte to a large megabyte object. Session will by default be stored in processes, so it will take up the server memory. It's easy to use tools or do a simple math to calculate how much memory my objects will take up times the numbers of users of the system, by doing so we can see if we have enough memory to store our object into Sessions. But we often forget about the other kind of  "hidden" users that will access our applications, users that sneaks into our application and will steal resources, those kind of predators and shadows walkers are known as Competitive intelligence companies and robots. They are also users in our system so we can't just only take the size of our objects times our users of the system. We need to have the other users in consideration. By using Sessions we can ran out of memory when we least suspect it.

When working with Sessions it can be advisable to use a weak reference instead of a strong reference. A weak reference allows the garbage collector to collect an object while still allowing an application to access the object. If we use strong references we can end up with an Out of Memory Exception sooner of later in our Web application, because the Session takes up all the memory. If we use a weak reference we will not get an Out of Memory Exception because when we start to run out of memory, garbage collection will remove our weak references form the memory. Even if we use a weak reference we can till obtain a strong reference to it and prevent it from being collected.

Every time I try to get a value our from a Session, I check if it has any value, I never assume I have a value. I have seen several application where developers just grab and object out from the Session as they was 100% sure it exists, like this: 

MyObject object = (MyObject)Session["Key"];
object.MyMember();

or even worse:

((MyObject)Session["Key"]).MyMemeber();


How can you be 100% sure that your Session will still be in memory? Have you change the default timeout of the Session to be infinitive, just a thought ;)

A good practice is to check if the value exists before to use it, it can be done in several ways, the way I do is the following: 

MyObject myObject = Session["Key"]) as MyObject;

if (myObject != null)


The problem with my code above is that I use a strong reference. So if I want to make sure to not get a Out of memory exception I should add a WeakReference to my Session and when I want to get a object out from my Session I should check if the Session have any data associated to the given key, and if, I turn the WeakReference into Strong reference.


The following code will make sure MyObject will be a WeakReference: 

Session["Key"] = new WeakReference(new MyObject());

And to make sure to get the object form the Session the following code can be used to turn a WeakReference to a strong reference: 

WeakReference reference = Session["Key"] as WeakReference;

if (reference != null)
{
   MyObject myObject = reference.Target as MyObject;
   if (myObject != null)
      myObject.MyMemeber();
}

If the garbage collection will not collect our WeakReference, the object will still be in the Session as normal and will be removed after a Session timeout. But if we start to run out of memory garbage collection can collect our object located in the Session, isn't that great!?

7 Comments

  • I've been using MVC and guess what... not a single need for a session yet :)

    It's nice.

  • Normen,

    I believe there's a bug in your last code example. There's a window between the IsAlive check and the call to Target. The Gargage Collector could have run in this time frame.


  • @svdeursen:
    Thanks, that is correct, I have updated the code, thanks for poiting it out!

  • Why not just use Cache? Is there any advantage using WeakReference with Session over Cache?

  • Cache is for all users... session is just for that one specific user.

  • Hi, nice article and good tip.
    But I think you can be sure that session will be in memory. a) if user requests after session has expired, your auth layer won't allow user to go to your business code; b) if session is still there it will be renewed each user request.

  • I only use the session to store small amounts of simple datatypes, such as the userId of the logged in user.
    The full userProfile can be accessed easily from my datastorage, where I use cache to store information.
    The idéa is to use the memory as much as possible. There's nothing good about free memory, as long as a garbage collector can free memory when needed.

Comments have been disabled for this content.