This Blog Has Been Moved !

This last week was great for learning. We had to setup our ASP.NET app on multiple web-servers/webcluster, the major issue in this case is that how session will be managed accross the cluster of webservers. ASP.NET Sessions can be managed in three ways, I’ll just go briefly here and then you can go through the references if you need details

1- In-Proc Session Management: This is what we have in a default ASP.NET application. The ASP.NET worker process aspnet_wp.exe manages all processes.

2- Centralized Session State Server: The second way in which the ASP.NET sessions can be managed is through the Session State Server, which is the session management out of the process, in other words you can set the sessions to be managed on a separate machine and then all the web-servers can access the user session from there. (In my opinion this is the best way to go for a webfarm) .NET Framework comes with a Session State Service which u can run from the SCM. There is a <sessionstate> attribute in the application web.config file which needs to be set for the state server and you are ready to go.

3- Session Management with SQL-Server: The last method is the session management through the SQL-Server; you can manage the session in a SQL Server DB.

Although, the Framework provides the mechanisms but changing the way your application manages the state is not seamless and there are a lot of consideration which are to be taken during the application design if you want to make your application scalable for such an environment.

If you are implementing sessions through state server or through SQL-Server, in other words managing sessions out of the process, the objects placed in the sessions are serialized/de-serialized on each access. Now you need to insure that all the objects that you keep in sessions are Serializable otherwise the application will crash which trying to serialize a non-serializable object. Framework provides support for the native objects so they seem to serialize without any problem, apart from them there are a lot of other built-In library classes which implement the ISerializable interface which make them inherently serializable, this includes the DataSet and DataTable objects which are commonly used through the sessions. Still, there are other objects that you keep in sessions and you need to make them serializable.

Serialization/De-Serialization also introduces a performance overhead but in a cluster environment you have to bear that cost to enhance the application performance.

Setting the serialization is not very difficult; you can set the [Serializable] attribute over a class to make this class serializable provided that all its members are either serializable or native types. There are various issues involved with setting a type as serializable including the security and performance issues and generally setting serialization for your classes is not recommended but there seems no other solution if we need to manage the session out of process.

Maybe while designing the application you can avoid the use of your custom types through sessions so don’t need to keep them in the session. You can also implement the ISerialiable and implement its GetObjectData() method to get a better control over serialization.

For furthur descussion about session states
http://www.msdn.microsoft.com/netframework/technologyinfo/infrastructure/tuning/default.aspx

For further discussion about the serialization issue http://msdn.microsoft.com/msdnmag/issues/05/09/SessionState/Default.aspx