IIS6: When an app pool is recycled, is Session_End called?

I need to know because I have to explicitly cl开发者_开发技巧ose some remote resources that are tied to the user's session.

I must disagree with Darin. I call a function in Session_End to record the end of the session. I have not tested this explicitly, but I looked in my logs for the last few times that the app pool recycled. The function got called and the end of the active sessions got logged.

This occurred both when the app pool recycled on a schedule, and when it recycled because I deployed some new dlls.

If I recall correctly (been a while since I read the docs) having active sessions will delay the normal App pool recycling timer (which fires when the resources should be freed) because the server banks on active sessions meaning that there is continued need. Once the sessions expire (and fire the session_end event) the app recycle timer starts over and counts down, eventually firing before the thread pool releases its own resources and terminates the app.

That is under normal circumstances, it should be noted that the session_end event is not guaranteed to fire (there use to be very specific scenarios where it would not), I think now this is mostly related to crashed instances of IIS or App Pool recycles for OOM or errors. It use to be unless you were using just one of the session types (state server I believe) it would not reliably fire. This may be different now.

If you need to guarantee that resources are freed, I am not sure session_end is the appropriate place to do it. Can you elevate it to the App Cache or HTTP Cache and use session unique keys with periodic cleanup events? That might be more reliable (more code) but more reliable.

It has been my general experience that session_end fires fairly reliably, but I have seen it fail under substantial load (100s of hits a second) and I know when you start talking about server farms it gets vastly more complicated as well.

Note too that Session_End is only called if you use the Inproc session mode. For other modes (including SQL session state mode) this event is never raised.