Asp.net session state server with SQL Server

Question

We're trying to get session state working using the following web.config line:

<sessionState 
    mode="SQLServer" 
    stateConnectionString="tcpip=127.0.0.1:42424" 
    sqlConnectionString="Data Source=dbServer;User ID=stateUser;Password='thepassword'" 
    cookieless="false" 
    timeout="20"/>

On dbServer, we've run the following command to set up the ASPState db:

aspnet_regsql.exe -S localhost-E -ssadd -sstype p

On the webServer, we've started the ASP.Net state service, however, no records show up in tables ASPStateTempApplications or ASPStateTempSessions, and it seems very much like session is still being stored in process.

What's wrong? Should the state service be running on the DB server? Does it get installed with IIS, because it's not available on that machine, despite .net 3.5.1 being installed.

The IIS logs show no hint of failure. What's wrong?

Answer 1

First, you don't need to start the State Service in order to use SQL Server session state. Forget about the ASP.NET State Service.

Are you sure that your site is creating a session variable? Just because you put these changes in your web.config, if you never use session variables, it won't be used.

Answer 2

If there's really quotes around the password, try to remove them:

sqlConnectionString="Data Source=dbServer;User ID=stateUser;Password=thepassword"

And remove the following line, it has no function for SQL session storage:

stateConnectionString="tcpip=127.0.0.1:42424" 

And you might as well stop the state service; it's needed for out-of-process session state, not for SQL Server session state.

Also, SQL Server session state requires you to run InstallSqlState.sql on the database, not aspnet_regsql.exe. It should create a new ASPState database.

Answer 3

How about writing a small HttpModule? You could drop it into place for the period of time when you need to transition users to the new codebase. The module could do some work on each page request to check the user's session and decide whether it needs to be abandoned. Perhaps you store an application version string in the user's session when the session is first created and compare the current app version string against that.