What actually causes Session_Start to be called?

Question

In a little demo application that I'm building I put code to initialize the database in the Global.Session_Start() event. However, I notice that this event does not fire when I'm running through the app in the debugger on the development server (haven't tested it anywhere else yet).

Question 1: What gives? When does Session_Start() actually get called? I assume it is when the session starts but shouldn't the beginning of every new sequence of requests cause a session to start automatically? Certainly a session should start whenever I run with F5 so why doesn't it.

Question 2: Is there a better place where the code to initialize the database should go? i would rather not put it in the Application_Start method, since it does not always get called when debugging.

PS. By initialize database I do not mean I open a connection to SqlServer and leave it open forever. I am using db4o and I open a pre-built database file. Like I said this is just a demo application, I'm not worried about poor resource management or anything like that.

Answer 1

What Session Model do you use? In case of SQL Server backed sessions, it may not start a new sessions. In case of InProc, I think it should work. Application_Start has the issue of being sometimes triggered before the debugger can attach, as you pointed out.

Do you use IIS or the Development Web Server? In case of IIS, this article suggest that you need to create it as an application first.

Answer 2

I'm not entirely sure that a session "starts" until you access the Session object. Otherwise it would seem like unnecessary overhead to fire up an unneeded session.

Answer 3

Hi George,

Hmm..ok. Maybe it would make sense to put the code in BeginRequest() but is there a way to put a handler at EndRequest() at which I can close the database file?

The issue is that you can never rely on these events to fire, because the ASP.NET runtime decides whether they are fired or not, because they might not even be necessary and can be skipped to save resources.

For example, a Response.Redirect cancels the whole processing of a request by using a ThreadAbortException, and the page/control lifecycle events after that will not be fired at all, that's why for example there is no End_Request or something similar.

I would consider moving your logic to a different layer (independent of ASP.NET), and maybe initialize the database when it's actually requested from a page? Then you can close the database file within the same method that you needed the information, this would make you much more independent of the state the application/session is in.

Not sure if this is the info you were looking for though :)