J
John
Hello,
We have developed a web application which uses ASP.Net to persist a
user's session state in SQLServer mode. The application makes use of
this feature in a 2 server web farm, which is fronted by a load
balancer. However the application is not picking up the session data
properly when failing over from one web server to the other.
We have tracked the problem down to an incorrect SessionID being used
to reference the data in the ASPStateTempSessions table. When
initially hitting the first server (ServerA), we see an entry being
generated in the ASPStateTempSessions table, then we see a second entry
being generated in the table when failing over to the second server
(ServerB).
The interesting thing about this is that the SessionIDs in these two
records are identical, except for the last eight characters. For
example:
ServerA - zruxqtixob0vi5mmbhexbl45e31b9bce
ServerB - zruxqtixob0vi5mmbhexbl452014c0f1
Also, when debugging on one of the servers, we can see the SessionID
being reported as only the first 24 characters of the value stored in
database (e.g. zruxqtixob0vi5mmbhexbl45). Therefore it seems as though
the SessionID is being picked up correctly from the client, however it
is not being referenced correctly between the web server and the
database.
We have also observed some consistency of the value of the last eight
characters when logged by any particular server. In other words:
ServerA will always append e31b9bce to the SessionID when referencing
the data in the database.
ServerB will always append 2014c0f1 to the SessionID when referencing
the data in the database.
Obviously the result of all this is that the session data is lost when
failing over to the secondary web server. Please let me know if anyone
else has experienced anything like this or knows of a solution.
Thanks.
John Fleming
(e-mail address removed)
We have developed a web application which uses ASP.Net to persist a
user's session state in SQLServer mode. The application makes use of
this feature in a 2 server web farm, which is fronted by a load
balancer. However the application is not picking up the session data
properly when failing over from one web server to the other.
We have tracked the problem down to an incorrect SessionID being used
to reference the data in the ASPStateTempSessions table. When
initially hitting the first server (ServerA), we see an entry being
generated in the ASPStateTempSessions table, then we see a second entry
being generated in the table when failing over to the second server
(ServerB).
The interesting thing about this is that the SessionIDs in these two
records are identical, except for the last eight characters. For
example:
ServerA - zruxqtixob0vi5mmbhexbl45e31b9bce
ServerB - zruxqtixob0vi5mmbhexbl452014c0f1
Also, when debugging on one of the servers, we can see the SessionID
being reported as only the first 24 characters of the value stored in
database (e.g. zruxqtixob0vi5mmbhexbl45). Therefore it seems as though
the SessionID is being picked up correctly from the client, however it
is not being referenced correctly between the web server and the
database.
We have also observed some consistency of the value of the last eight
characters when logged by any particular server. In other words:
ServerA will always append e31b9bce to the SessionID when referencing
the data in the database.
ServerB will always append 2014c0f1 to the SessionID when referencing
the data in the database.
Obviously the result of all this is that the session data is lost when
failing over to the secondary web server. Please let me know if anyone
else has experienced anything like this or knows of a solution.
Thanks.
John Fleming
(e-mail address removed)