Consideraciones de Arquitectura respecto al uso de Variables de Sesión

A continuación paso a enumera una serie de consideraciones a tener en cuenta y que os pueden ser íºtiles a la hora de tomar ciertas decisiones de arquitectura al respecto del uso de variables de sesión. Como veréis algunas de ellas tienen que ver con entornos .NET, ya que es la plataforma con la que suelo trabajar, pero la mayorí­a son aplicables a otros entornos tecnológicos no Microsoft.
Sesión en Memoria vs Sesión en Sistemas Persistidos (Base de Datos o Servicios del Sistema Operativo)

La forma más eficiente de trabajar con sesiones es manteniendo su contenido en memoria. En el caso de estar trabajando con una granja de servidores, pueden utilizarse soluciones existentes en el mercado como es NCache, para balancear el contenido de las sesiones en memoria entre todos los servidores de la granja.
En caso de no poder barajar esta alternativa existen soluciones que permiten almacenar el contenido de la sesión sobre sistemas persistidos. Esta solución es más lenta, pero permite compartir la información de sesión sobre diferentes servidores, además de garantizar que aunque se reinicie el servidor de aplicaciones, la información de sesión va a permanecer disponible cuando la aplicación vuelva a arrancarse.
Cantidad de Memoria en Uso
El uso de sesión afecta directamente al consumo de memoria del servidor que está ejecutando las llamadas del cliente, por lo que deberá almacenarse en sesión íºnicamente la información que se considera imprescindible y que, se recomienda, esté relacionada con alguna de las siguientes caracterí­sticas:

• Información básica relacionada con la autenticación o la seguridad del usuario y que es necesario comprobar en las llamadas o peticiones que realiza el usuario contra la aplicación.
• Otro tipo de información funcional asociada al usuario, que va a permanecer estática a lo largo de toda la vida de la sesión y que es requerida de forma constante en las peticiones que realiza el usuario a la aplicación. El objetivo de este punto serí­a minimizar el níºmero de llamadas a base de datos.

Tipos de Objetos en Memoria
Los objetos almacenados en la sesión deben ser en todo caso de poco peso, minimizando así­ la cantidad de información almacenada por sesión por cada objeto. Se recomienda el uso de objetos de negocio que incluyan tipos de datos básicos. No se recomienda el almacenamiento de objetos propietarios de .NET del tipo Dataset ó DataTable debido al tamaño asociado a los mismos.
Manejando Información Sensible
Si el contenido almacenado en la sesión contiene información sensible, como podrí­an ser contraseñas o información personal del usuario activo, ésta deberá permanecer encriptada durante todo el ciclo de vida de la sesión.
Usando Sesión a modo de Caché
No debe emplearse la sesión para almacenar catálogos de datos comunes de la aplicación, como podrí­an ser listados de paí­ses, regiones, provincias, etc, ya que éste no es el objetivo de  este tipo de objeto. Para estos casos se deberá recurrir a un objeto de tipo caché.
Usando Sesión a modo de Viewstate (especí­fico .NET)
No se recomienda emplear la sesión para almacenar información que será necesaria explotar entre llamadas a la misma página, ya que para ello existe un objeto preparado especí­ficamente para resolver esta problemática como es el Viewstate de ASP.NET.
Usando Sesión a modo de POST y GET
No debe emplearse la sesión para transportar información entre páginas de la misma aplicación, ya que para ello se deberá recurrir a los objetos POST y GET.
Liberando Información de Sesión
Siempre y cuando se detecte que la información almacenada en sesión deje de ser necesaria para la sesión de usuario actual, se debe solicitar la liberación de la memoria asociada al servidor.
Saludos.
Miguel.