While the ASP.NET session state is nearly identical to the Session object of ASP in its use, it is significantly richer in functionality and radically different in architecture. In addition, the ASP.NET Session object provides some extremely handy facilities, such as the support for cookieless browsers, web farms and web gardens, and the capability of being hosted by external processes, including SQL Server. In this way, ASP.NET session management can provide an unprecedented level of robustness and reliability. In ASP.NET, the session state is implemented through an instance of the HttpSessionState class. The programming interface of the HttpSessionState looks similar to ASP, but more importantly, the internal architecture has been tuned to provide the best throughput in what appeared to be the most common usage scenario (according to reports and statistics). The ASP.NET session state mechanism is optimized for situations in which reading and writing operation are well balanced and occur with roughly the same frequency.
Immediately after the request processing started, the ASP.NET runtime instantiates the HttpSessionState object, which when invoked reads the settings from the <sessionState> section of the web.config file. By reading the configuration file, the module can determine what the expected state client manager for the application is. There are three possibilities: The session state can be stored locally in the ASP.NET worker process (InProc mode); the session state can be maintained in an external, even remote, process called aspnet_state.exe (StateServer mode); and finally, the session state can be managed by SQL Server and stored in an ad-hoc database table (SQLServer mode).
The InProc option is by far the fastest possible in terms of speed access. However, bear in mind that the more data you store in session, the more memory is consumed on the web server, increasing the risk of performance hits. If you plan to use any of the out-of-proc solutions, the possible impact of serialization and deserialization should be carefully considered.
At least when the session is implemented through the InProc state provider, each active session is characterized by an item placed in the ASP.NET cache system. The name of the item has the following form:
System.Web.SessionState.SessionStateItem:[session ID]
The value for the item corresponds to an instance of an internal class called SessionStateItem, completely inaccessible from outside the system.web assembly, even through reflection. However, simply counting the items in the ASP.NET cache whose name matches the pattern above, you can easily arrange a procedure to detect how many sessions are active and obtain their ID. The listing below shows how to populate a DataTable with the ID of all the active sessions.
DataTable dt = new DataTable();
dt.Columns.Add("SessionID", typeof(string));
foreach(DictionaryEntry elem in Cache) {
string s = elem.Key.ToString();
if (s.StartsWith("System.Web.SessionState.SessionStateItem")) {
DataRow row = dt.NewRow();
char[] parms = {':'};
string[] a = s.Split(parms);
row["SessionID"] = a[1];
dt.Rows.Add(row);
}
}
If the session is working in SQLServer mode, the number of active sessions can be determined accessing the SQL Server database where all the information is stored. The necessary infrastructure is created running a SQL script called InstallSqlState.sql. The script called UninstallSqlState.sql, instead, removes the necessary tables. Both scripts are located under the directory:
C:\WINNT\Microsoft.NET\Framework\v1.0.3705
The session state is stored in a database called ASPState. The database includes several stored procedures and creates a couple of tables to the TempDB database. The tables are called ASPStateTempApplications and ASPStateTempSessions. Knowing how many sessions are currently active is as easy as running a SELECT against the AspStateTempSessions table. If the session is working in StateServer mode, none of these tricks will work.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Magazine and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and ADO.NET and Applied XML Programming for .NET. Contact Dino at [email protected].
