Hoy en el trabajo observamos un comportamiento un poco extraño relacionado con la información que almacenamos en Sesión y que utilizamos en una Web Application corriendo en un pequeño WebGarden teniendo configurado como Session State Server la opción de SQL Server.
Algunos links sobre Session State y la opción de SQL Server Session Mode
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!
