What is really stored in Session in ASP.NET?

Question

We are trying to decide how to handle object persistence accross postbacks, to avoid getting the data from the database in every request, and I'm leaning towards using Session (it's an intranet application, there won't be thousands of users), but this is due to the fact that I suspect that only the reference to the real object is stored there...

Does anyone know for a fact if this is true?

I've always been taught not to over use the session object, but if it works this way it wouldn't really be a big problem...

What is really stored in session here:

Session["myKey"] = myObject;

The actual serialized object, or its reference?

Answer 1

ASP.NET creates a GUID that is stored in a cookie by default (but you can specify the use of the querystring) to identify the user. The objects associated with that cookie are stored on the server within the IIS process by default.

You can also create custom session object stores (Session-State Store Providers), for example if you wanted to keep session objects out-of-process.

More info here:

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

But to actually answer your question...

Out of the box, you are correct in the assumption that the session store stores only a reference to the object.

Although, you can specify the storage behavior of the session functionality in the web.config I believe, to achieve serialization too. The 3 modes:

• InProc - session kept as live objects in web server (aspnet_wp.exe). Use "cookieless" configuration in web.config to "munge" the sessionId onto the URL (solves cookie/domain/path RFC problems too!)
• StateServer - session serialized and stored in memory in a separate process (aspnet_state.exe). State Server can run on another machine
• SQLServer - session serialized and stored in SQL server

The above is from: http://www.eggheadcafe.com/articles/20021016.asp

Answer 2

It's depends what session you use , if you using inproc session you in did strore the referense in session , but while reference it self it just a link to an object it keeps the whole object inside the proccess memory, so when you design you application is higly desirable to know how much data you will have per user and how many active users you will have per hour. The object inside the proccess memory is not serialized if you use in proc session but it is serialized if you use out of proc session , it can have implecations on performance.

I think here you can find very good overview of session and cache

Answer 3

It's important to remember that In-Proc Session data is fairly fragile...meaning it may not be there when you most need it. If the worker process recycles for any reason poof it's gone.

Answer 4

I understand you do not have a lot of performance concerns right now and session would probably work fine; however there are other ways of maintaining state or carrying data across postbacks.

If you are trying to persist data across postbacks of the same page then I would recommend using the ViewState instead. Note that data stored in the ViewState is serialized and any object you would like to persist must implement ISerializable.

Answer 5

Hi,

I have tried this:

I have created a class and store an instance of this in session (session state mode: InProc). Instance lives in aspnet_wp.exe proc.

Then, I changed session state to SQL Server (still without [Serializable] attribute) and I got the following error.

Unable to serialize the session state. In 'StateServer' and 'SQLServer' mode, ASP.NET will serialize the session state objects, and as a result non-serializable objects or MarshalByRef objects are not permitted.

So, there is no serialization for inProc session state.

Cheers... Martín

Answer 6

There are tons of articles and blog posts that bemoan the use of storing complex objects (technically storing references to said objects) in session variables. Generally,I think that session variables are the devil's work and do all that I can to avoid them.

That said, for an intranet-deployed app, where the developer fully understands the scalability impact of overusing session session as Juan Manuel describes, I've done that many times and with great success. Yes, the session can recyle, but that's a unusual, edge case--that doesn't occur regularly enough to affect browser apps with rational session timeout.

I'd say build the app the way you suggest, Juan Manuel, at least at first. But squirrel away where you're saving and getting objects from the session (with a wrapper class perhaps) so that should the application demand, it's easy to change later.