In a web application the role of session management is very critical. Most of the languages available today do not really support different modes of session management. They used to follow the traditional way of maintaining the session that is through web servers.

But in .NET applications we have multiple options to opt for the session mode. The different session management modes available in .NET technology are InProc, SQLServer and State Server. Among them, InProc is the default method that keeps the session in Web servers (IIS).

If Session management mode is SQL Server, then all the sessions and session variables are getting stored in a SQL Server. To make this type of session management active we need to do the following changes in Web.Config.

We need to modify the sessionState mode = "InProc" to "SQLServer."

We need to give the appropriate connection string for the SQLServer: [sqlConnectionString="data source=127.0.0.1;user id=sa; password=xxxx"].

We also need to create the DB structure, which will actually hold our sessions and session variables. For that we need to perform the following step.

Find the InstallSqlState.sql file at [system drive\ Windows\ Microsoft.NET\ Framework\version\].

Run this script for the SQLServer that is going to maintain the session.

This script will create the necessary DB structures to maintain the session in the SQL Server.

Now it is all ready to use the SQL Server Session management.

There is a problem in InProc Mode of session management- it clears all the sessions when the worker process re-starts. But this can be solved easily when the mode is SQL Server. It keeps the sessions away from the Web Server and solves the above stated issue.

In the case of InProc mode, you can keep anything in session. This anything includes simple variables to complex objects. But there are some limitations for SQL Server Session management. You simply cannot dump the variables into the session that you used to do in InProc mode. In SQL Server mode the session variables are getting Serialized and then stored in SQL Server. Similarly, you need to De-Serialize them while retrieving.

From the above point it can be easily understood that, in SQL Server mode, you cannot store the objects which are not Serializable. To store complex objects into sessions you have to make them Serialized.

Performance also plays a role here. In InProc mode you can directly store and retrieve the values, but in SQL Server management it internally hits the database each time for any session related matters hindering the performance of the application.

Apart from that, Serialization and DeSerialization is also a needed requisite for SQL Server session mode.

So far we have learned that SQL Server stores sessions exploiting the process of Serialization. Now, let us dig a bit more into it. Serialization is noting but the act of producing an item in the form of memory bytes.

For the process of serialization we need two things. One is a Formatter and another is a Stream Object.

The Serialize method of the Formatter object actually does everything that is required.

Let us see the code for this purpose. The class written below is the class whose object is going to be serialized. For that purpose, the <Serializable()> attribute are added.

Listing 1

<Serializable()> Public Class DataDescription
  Public Data As Integer
  Public Description As String
 
  Public Sub New(ByVal NewData As Integer, ByVal NewDescription As String)
    Data = NewData
    Description = NewDescription
  End Sub
 
  Public Overrides Function ToString() As String
  Return Description
End Function
 
End Class

The code below shows the actual method of Serialization.

Listing 2

Public Function SerializeData( _
ByVal oDataToBeSerialized As Object) As System.IO.MemoryStream
  Dim oFormatter As New _
    System.Runtime.Serialization.Formatters.Binary.BinaryFormatter()
  Dim oStream As New System.IO.MemoryStream()
  oFormatter.Serialize(oStream, oDataToBeSerialized)
  Return oStream
End Function

Deserialization is the process of using the serialized state information to regain the object from the serialized shape to its original shape.

So, it is basically the reverse process of the Serialization. (The name also suggests De-Serialization)

The code below can be used for the De-serialization process.

Listing 3

Public Function DeSerializeData(ByVal oStream As System.IO.MemoryStream) _
As Object
  Dim oFormatter As New _
    System.Runtime.Serialization.Formatters.Binary.BinaryFormatter()
  Dim oReturnObject As Object
  oStream.Position = 0
  oReturnObject = oFormatter.Deserialize(oStream)
  Return oReturnObject
End Function

The function DeSerializeData De-serializes a MemoryStream (which has been obtained by Serializing a Serializable object).

Here we need to add an extra line to seek the position of the MemoryStream to ZERO (0).

As we have already discussed at the beginning of this article, SQL Server Session management requires the Serialization and De-Serialization process to store the session values in the Database. And this requirement becomes more prominent when we will try to dump an object directly to the Session. Because the integers, strings, etc. can be directly stored/retrieved to and from the Session (as it goes through the internal conversion actually), for objects we need to do the process by our own.

For that we need to exploit the Serialization and De-Serialization process. Let us see the example doing the same below.

Listing 4

Dim oDataDescription As New DataDescription(0, "ZERO")
'Serializes the oDataDescription object and stores the serialized data in Session
Session.Add("test", SerializeData(oDataDescription))
'De-serializes the Data from the Session 
'and brings the object into its original shape.
oDataDescription = DeSerializeData(Session.Item("test"))
Response.Write("Data: " & oDataDescription.Data & "<br>")
Response.Write("Description: " & oDataDescription.Description)

Advantages

It keeps the session in the database and not on the Web Server (IIS) making the server memory free for other usage.

It allows the session objects to be shared among other applications like ASP, PHP, etc.

Leads to Web farming and web gardening.

Disadvantages

Brings the performance Issues into the picture due to the Database round trips.

It also goes through the process of Serialization and De-Serialization every time, which is another overhead.

It forces all the classes whose objects are going to be stored in session declared as Serializable().

It forces you to define the class in a specific way.

It cannot use any other database except the SQL Server.

We have already discussed few things on the SQL Server Session management and it seems like a mix of both good and bad. We need to be careful from the performance point of view while storing the values in session. Unnecessary dumping of objects into sessions may lead to performance hazards. So, just put enough thought into it before going for the SQL Server Session management.