¿Qué causa realmente que se llame a Session_Start?

Question

En una pequeña aplicación de demostración que estoy construyendo pongo código para inicializar la base de datos en el evento Global.Session_Start(). Sin embargo, veo que este evento no se dispara cuando estoy ejecutando la aplicación en el depurador en el servidor de desarrollo (aún no lo he probado en ningún otro lado).

Pregunta 1: ¿Qué ocurre? ¿Cuándo se llama realmente a Session_Start()? Supongo que es cuando comienza la sesión, pero ¿no debería el comienzo de cada nueva secuencia de solicitudes provocar que una sesión se inicie automáticamente? Ciertamente, una sesión debería comenzar cada vez que corro con F5, ¿por qué no?

Pregunta 2: ¿Hay algún lugar mejor donde debería ir el código para inicializar la base de datos? Preferiría no ponerlo en el método Application_Start, ya que no siempre se llama cuando se depura.

PS. Al inicializar la base de datos no quiero decir que abro una conexión a SqlServer y la dejo abierta para siempre. Estoy usando db4o y abro un archivo de base de datos preconstruido. Como dije, esto es solo una aplicación de demostración, no me preocupa la mala gestión de los recursos ni nada de eso.

Answer 1

No estoy del todo seguro de que una sesión "comience" hasta que acceda al objeto Session. De lo contrario, parecería una sobrecarga innecesaria disparar una sesión innecesaria.

Answer 2

¿Qué modelo de sesión usas? En el caso de las sesiones respaldadas por SQL Server, es posible que no comience una nueva sesión. En el caso de InProc, creo que debería funcionar. Application_Start tiene el problema de que a veces se desencadena antes de que el depurador pueda conectarse, como ha señalado.

¿Utiliza IIS o el servidor web de desarrollo? En el caso de IIS, this article sugiere que primero debe crearlo como una aplicación.

Answer 3

Hmm..ok. Tal vez tendría sentido poner el código en BeginRequest() pero es hay una manera de poner un controlador en EndRequest() en el que puedo cerrar el archivo de base de datos ?

La cuestión es que nunca se puede confiar en estos eventos al fuego, ya que el tiempo de ejecución de ASP.NET decide si son despedidos o no, porque no puede ser que incluso sea necesario y se pueden saltar para ahorrar recursos.

Por ejemplo, Response.Redirect cancela el procesamiento completo de una solicitud utilizando una ThreadAbortException, y los eventos del ciclo de vida de la página/control después de eso no se dispararán en absoluto, por eso, por ejemplo, no hay End_Request o algo similar .

Consideraría mover su lógica a una capa diferente (independiente de ASP.NET), y tal vez inicializar la base de datos cuando en realidad se solicita desde una página? Luego puede cerrar el archivo de la base de datos con el mismo método que necesitaba la información, esto lo haría mucho más independiente del estado en que se encuentra la aplicación/sesión.

No estoy seguro si esta es la información que estaba buscando :)

Answer 4

sé que esto es una entrada antigua, pero tal vez esto ayude a alguien:

el session_start no se dispara a menos que en realidad se está leyendo o escribiendo en el objeto de sesión.

Si desea utilizar el caso session_start pero no es necesario utilizar el almacenamiento de sesión en absoluto, usted puede añadir lo siguiente a la directiva de página de las páginas de destino:

<%@ Page EnableSessionState="ReadOnly" %> 

Esto hará que el evento session_start para disparar sin tener que almacenar nada en el objeto de sesión.