Qué poner en una variable de sesión

Question

Recientemente me encontré con una aplicación web ASP 1.1 que puso todo un montón de cosas en la variable de sesión, incluidos todos los objetos de datos DB e incluso el objeto de conexión DB. Termina siendo enorme. Cuando finaliza el tiempo de espera de la sesión web (cuatro horas después de que el usuario ha terminado de usar la aplicación), a veces se retrotraen sus transacciones de base de datos. Supongo que esto se debe a que la conexión DB no se cierra correctamente cuando IIS elimina la sesión.

De todos modos, mi pregunta es ¿qué debería estar en la variable de la sesión? Claramente, algunas cosas deben estar ahí. El usuario selecciona qué plan quiere editar en la pantalla principal, de modo que la identificación del plan se inserta en la variable de sesión. ¿Es mejor intentar y reducir la carga en el DB almacenando todos los detalles sobre el usuario (y su administrador, etc.) y el plan que están editando en la variable de sesión o si debo tratar de minimizar las cosas en la variable de sesión y consultar el DB para todo lo que necesito en el evento Page_Load?

Answer 1

esto es bastante difícil de responder porque es muy específica de la aplicación, pero aquí hay algunas pautas que utilizo:

1. puso lo menos posible en la sesión.
2. Las selecciones específicas del usuario que solo deberían durar durante una visita determinada son una buena opción
3. a menudo, variables que deben ser accesibles a varias páginas a lo largo de la visita del usuario a su sitio (para evitar pasarlas de página a página) también son buenos para poner en la sesión.

Por lo poco que ha dicho sobre su aplicación, probablemente seleccionaría sus datos de la base de datos e intentaría encontrar maneras de minimizar el impacto de esas consultas en lugar de cargar la sesión.

Answer 2

DO NOT put UI objects in session.

más allá de eso, yo diría que varía. Demasiada sesión puede ralentizarlo si no está utilizando la sesión en proceso porque va a serializar mucho + la velocidad del proveedor. La memoria caché y la sesión deben usarse con moderación y cuidado. No te pongas en sesión porque puedes o es conveniente. Siéntate y analiza si tiene sentido.

Answer 3

Do no poner la información de conexión de la base de datos en la sesión.

Por lo que respecta al almacenamiento en caché, evitaría usar la sesión para el almacenamiento en caché si fuera posible: se encontrará con problemas en los que otra persona cambia los datos que utiliza un usuario, además no puede compartir los datos almacenados en caché . Use ASP.NET Cache, o alguna otra utilidad de almacenamiento en caché (como Memcached o Velocity).

En cuanto a lo debe ir en la sesión, cualquier cosa que se aplica a todos los ventanas del navegador de un usuario tiene abierto a su sitio (inicio de sesión, la configuración de seguridad, etc.) deben estar en la sesión. Cosas como qué objeto se está viendo/editando realmente deberían ser variables GET/POST pasadas entre las pantallas para que un usuario pueda usar múltiples ventanas del navegador para trabajar con su aplicación (a menos que quiera evitar eso).

Answer 4

A very similar question se le preguntó con respecto a las sesiones de PHP anteriores. Básicamente, las Sesiones son un excelente lugar para almacenar datos específicos del usuario a los que debe acceder a través de varias cargas de página. Las sesiones NO son un gran lugar para almacenar referencias de conexión de bases de datos; sería mejor usar algún tipo de software de agrupación de conexiones o abrir/cerrar su conexión en cada carga de página.En cuanto a los datos de caché en la sesión, esto depende de cómo se almacenan los datos de la sesión, cuánta seguridad necesita y si los datos son específicos del usuario o no. Una mejor apuesta sería usar algo más para almacenar datos en caché.

Answer 5

almacenar señales de navegación en las sesiones es complicado. El mismo usuario puede tener varias ventanas abiertas y luego los cambios se propagan de manera confusa. Las conexiones DB deben definitivamente no almacenarse. ASP.NET mantiene el grupo de conexiones para usted, sin necesidad de recurrir a su propia hechicería. Si necesita almacenar cosas en caché por períodos cortos y el tamaño del conjunto de datos es relativamente pequeño, mire en ViewState como una posible opción (a costa de cargar más bulto en el tamaño de la página)

Answer 6

A: Datos que solo son relativos a un usuario. IE: un nombre de usuario, una identificación de usuario. En most un objeto que representa a un usuario. A veces, los datos relativos a la URL (como dónde llevar a alguien) o una pila de mensajes de error son útiles para ingresar a la sesión.

Si desea compartir cosas potencialmente entre diferentes usuarios, use la tienda de aplicaciones o la memoria caché. Ellos son muy superiores.

Answer 7

Stephen,
¿Trabajas para una empresa que comienza con "I", que tiene un sitio web que comienza con "BC"? Eso suena exactamente como lo que hice cuando comencé a desarrollar en .net (y era joven y estúpido) - Atrévete con todo lo que podía pensar en sesión y aplicación. Huelga decir que eso era doblemente bueno.
En general, evite la sesión tanto como sea posible. Ciertamente, los objetos no serializables no deberían almacenarse allí (conexiones de bases de datos y demás), pero incluso los objetos grandes y serializables tampoco deberían estar almacenados. Simplemente no quieres la sobrecarga.

Answer 8

Idealmente, la sesión en ASP debería almacenar la menor cantidad de datos que pueda obtener. Almacenar una referencia a cualquier objeto que contenga recursos del sistema abiertos (particularmente una conexión de base de datos) es un asesino de escalabilidad definitivo. Además, almacenar datos no confirmados en una variable de sesión es solo una mala idea en la mayoría de los casos. En general, parece que la implementación actual está abusando de los objetos de sesión para tratar de simular una aplicación con estado en un entorno supuestamente sin estado.

aunque es mucho difamado, el modelo de gestión de ASP.NET de estado de forma automática a través de campos ocultos en realidad debería eliminar la mayor parte de la necesidad de mantener nada en variables de sesión.

Mi regla de oro es que cuanto más escalable (en términos de usuarios/visitas) que la aplicación debe ser, menos puede escaparse usando el estado de la sesión. Sin embargo, hay una compensación. Para aplicaciones web donde el usuario accede repetidamente a los mismos datos y normalmente tiene una sesión bastante larga por uso del sitio, cierto almacenamiento en caché (si es necesario en objetos de sesión) puede ayudar a la escalabilidad al reducir la carga en el servidor de bases de datos. La idea aquí es que es mucho más barato y menos complejo cultivar la capa de presentación que la base de datos DB. Por supuesto, con todas las cosas, este consejo debe tomarse con moderación y no se aplica en todas las situaciones, pero para una aplicación CRUD interna bastante simple, debería servirle bien.

Answer 9

Siempre mantendría muy poca información en sesión. Las sesiones usan recursos de memoria del servidor que es costoso. Ahorro de demasiados valores en sesión aumenta la carga en el servidor y consiguiera el rendimiento del sitio va a bajar. Cuando utiliza servidores de equilibrio de carga, el uso de la sesión puede tener problemas. Entonces, lo que hago es usar sesiones mínimas o sin sesiones, usar cookies si la información no es muy crítica, usar campos ocultos más y sesiones de bases de datos.