Serialized In-Process ASP.NET Session State Store

 


ASP.NET provides out of the box three session state stores:
















Provider Description
InProc

Session state is stored in the ASP.NET cache.

SQLServer

Session state is stored out-of-process in an SQL Server database.

StateServer

Session state is stored out-of-process in an ASP.NET state service.


Because with SQLServer and StateServer providers the state must cross the AppDomain boundary it needs to be serialized when stored and deserialized when loaded. Because the state needs to be loaded and stored on each request, it is only available from the PostAcquireRequestState to the ReleaseRequestState events. And, because of serialization and deserialization, all objects stored must be serializable any reference held to one of the session state items won’t be to the same item after being deserialized.


On the other hand, with the InProc provider, the state will never be serialized or deserialized, which means that objects don’t need to be serializable and any reference to an item in the state is always a reference to the item in the state even before the PostAcquireRequestState event and after the ReleaseRequestState event.


In practice, developers use the InProc provider and applications are deployed to production using the SQLServer provider. This usually leads to application errors, like storing non serializable objects in the state, that are only uncovered in production. That’s why I’ve written a serializable in-process session state store. You can find the sources here.

2 Responses to Serialized In-Process ASP.NET Session State Store

  • Pål A. says:

    A cool project, but I cannot really see the need. Isn’t it much better to have your developers use the SQLServer provider instead? SQL Server Express is free and uses little extra resouces on your developers machines. The more similar the development system is to the production system the better.

    Also, putting stuff in session that requires serialization is not a good idea. As little as possible should be in session, and if you really require to use session, only add sinple types and integers, strings etc.

    If you feel the need to store complex structures and linked objects then you need to retake that ASP.NET programming class 🙂

  • paulo says:

    I mostly agree with you, Pål, but…

    This is a step closer to the use of SQL Server in production environments. Probably as closer as using SQL Server Express or SQL Server Developer Edition. How many developers stress the session state database to simulate the production environment?

    All the stuff that you put in the session state needs serialization. I think that what you meant was that only primitive types should be put in the session state. This is a good practice in theory. If you only put primitive types in the session state you won’t have deserialization problems when a partial update to the application happens and the type of an item in the session state has changed. Also avoids throwing large objects into the session state.

    On the other hand, in the real world, sometimes you save stuff in the session state because it’s expensive to obtain and doesn’t change throughout the duration of the session. Why have another transitory persistence system?

    If you are building composite applications, you might be a module developer and your module might be used in a big application running on a big web farm or a small application running on a single server. Why should you need a SQL Server for such a small application? But the provided InProc provider just doesn’t work the same way as the SQLServer or StateServer ones.