Does asp.net lifecycle continue if I close the browser in the middle of processing?

Question

I have an ASP.NET web page that connects to a number of databases and uses a number of files. I am not clear what happens if the end user closes the web page before it was finished loading i.e. does the ASP.NET life cycle end or will the server still try to generate the page and return it to the client? I have reasonable knowledge of the life cycle but I cannot find any documentation on this.

I am trying to locate a potential memory leak. I am trying to establish whether all of the code will run i.e. whether the connection will be disposed etc.

Answer 1

The code would still run. There is a property IsClientConnected on the HttpRequest object that can indicate whether the client is still connected if you are doing operations like streaming output in a loop.

Answer 2

Once the request to the page is generated, it will go through to the unload on the life cycle. It has no idea the client isn't there until it sends the information on the unload.

A unique aspect of this is the Dynamic Compilation portion. You can read up on it here: http://msdn.microsoft.com/en-us/library/ms366723

For more information the the ASP.NET Life Cycle, look here: http://msdn.microsoft.com/en-us/library/ms178472.aspx#general_page_lifecycle_stages

So basically, a page is requested, ASP.NET uses the Dynamic Compilation to basically create the page, and then it attempts to send the page to the client. All code will be run in that you have specified in the code, no matter if the client is there or not to receive it.

This is a very simplified answer, but that is the basics. Your code is compiled, the request generates the response, then the response is sent. It isn't sent in pieces unless you explicitly tell it to.

Edit: Thanks to Chris Lively for the recommendation on changing the wording.

Answer 3

You mention tracking down a potential memory leak and the word "connection". I'm going to guess you mean a database connection.

You should ALWAYS wrap all of your connections and commands in using clauses. This will guarantee the connection/command is properly disposed of regardless of if an error occurs, client disconnects, etc.

There are plenty of examples here, but it boils down to something like:

using (SqlConnection conn = new SqlConnection(connStr)) {
  using (SqlCommand cmd = new SqlCommand(conn)) {
     // do something here.
  }
}

If, for some reason, your code doesn't allow you to do it this way then I'd suggest the next thing you do is restructure it as you've done it wrong. A common problem is that some people will create a connection object at the top of the page execution then re-use that for the life of the page. This is guaranteed to lead to problems, including but not limited to: errors with the connection pool, loss of memory, random query issues, complete hosing of the app...

Don't worry about performance with establishing (and discarding) connections at the point you need them in code. Windows uses a connection pool that is lightning fast and will maintain connections for as long as needed even if your app signals that it's done.

Also note: you should use this pattern EVERY TIME you are using an un-managed class. Those always implement IDisposable.