6
votes

So I set up SQL Server Session State using SQL Server 2008 and the temp database and today I decided to look into the data in the tables only to find this in the ASPStateTempApplications table:

AppId AppName
538231025 /lm/w3svc/1/root
611758131 /lm/w3svc/3/root
802488340 /lm/w3svc/4/root
-940085065 /lm/w3svc/4/root/webapp
685293685 /lm/w3svc/5/root
1210055478 /lm/w3svc/5/root/webapp

We have 2 load balanced web servers.

When I look into the ids of the web apps of both servers I see that web1 has app1 with id 4 and web2 has app1 with id 5. The same thing happens with the other app. web1 has app2 with id of 1 and web2 has app2 with id of 3.

My common sense tells me that the web servers are not sharing sessions as the session id uses the appid. Am I correct? If so why isn't this minor detailed not so obvious in the documentation? Should I make the ids match on both web servers?

1

1 Answers

6
votes

The AppId is used during the creation of the SessionId, to help avoid collisions from one app to another. It's created by computing a hash of the IIS app path.

In your environment, the flow might be something like this:

  1. Server A creates a session ID, sets it in a cookie, and stores some data in the corresponding session (a row in ASPStateTempSessions). The session ID column is created by concatenating the session ID with the AppID.
  2. Server B receives a request with a pre-existing session ID, and uses it to find the associated session data from the ASPStateTempSessions table. If the app ID is different, the generated key will also be different.

The net effect of having multiple servers with different AppIds that are sharing the same sessions is that IDs created by one server won't collide with those from another server, and machines with different AppIds won't see each other's sessions.