Algunos links sobre Session State y la opción de SQL Server Session Mode

Overview en CodePoject

How-To de Microsoft Support

Fast, Scalable, and Secure Session State Management for Your Web Applications

En ocasiones, al cambiar de servidor dado a la distribución que realiza un load balancer, la aplicación parecía no poder obtener la información almacenada en sesión y por ende no poder continuar con el proceso que debía desarrollar. Al momento de revisar la base de datos de sesión pudimos percatarnos que habían 2 tuplas para una misma ASP.NetSessionId

Query: select * from ASPStateTempSessions where SessionId like '%piltae45debwl355ek3v0545%'

Y cómo es esto? Ok, resulta que el SessionId que utilizamos en nuestra aplicación no es lo único que se utiliza como llave en la tabla de SQL ya que está formada por:

Session Id + Application Id

(ver mas info acá: Session State Providers)

Resultó entonces que por cada servidor nos estaba generando una tupla en nuestro storage de sesión, la primera con la información que habíamos almacenado y la segunda como una nueva sesión totalmente vacía. Esto debido a que a cada webserver le estaba asignando un diferente Application Id.

Me dirán por ahí que esto no debía suceder… también hay un trasfondo relacionado con la aplicación que casualmente permite esto, sin embargo esto lo dejamos para otro post

Solución:

Debemos irnos a cada uno de los webservers del WebGarden y en cada uno debemos definir el “ID” del website. Para ello debemos colocarnos en “Sites”

Dar click derecho y en “Manage Web Site” seleccionamos la opción “Advanced Settings”

y finalmente nos aseguramos que el Website en cada uno de los Web Servers de nuestro WebGarden tenga el mismo ID

Reiniciamos los IIS para que todo camine en orden y voila!