views:

21

answers:

1

As best I can tell when a worker process recycles:

a) a new one spins up before the old one shuts down b) the old one shuts down once all the active requests its servicing completes

Is the above accurate?

If so, I have data that I store in SQL once Application_End() fires from the global.ascx file. I pull this data back in when Application_Start() fires.

The problem is based on my testing, the new worker process fires the Application_Start() before my old worker process gets a chance to complete its Application_End().

What are best practices for handling this situation?

cheers in advance

edit: I just noticed a feature on IIS 7 'Disabled Overlapped Recycle' - I'm guessing this is the best route

+1  A: 

Your description of overlapped recycling is accurate, yes (1); and there is a setting for disabling it, but it's intended to prevent HTTP errors which you would be re-introducing. App pool recycles are a normal occurrence for managed apps (stems from, among other things, a CLR limitation that prevents the unloading of assemblies in the same memory space) that you must design for.

Your technique would be difficult to manage in a web-farm or web-garden scenario.

I think a better design would be to rely on out-of-process storage for the data (using distributed cache products like ScaleOut, App Fabric, and the like) so that all app pools have the same view of the cached data.

(1) - http://mvolo.com/blogs/serverside/archive/2008/02/25/Starting_2C00_-stopping-and-recycling-IIS-7.0-Web-sites-and-application-pools.aspx

Nariman
Yes I agree, this approach leaves me in a conundrum if our application scales and needs to head in the web-farm/garden scenario. Are there any free distributed cache products - I'm guessing most have a significant cost?
Windows Server AppFabric is a free extension to Windows Server - also expected to be a native component of future Windows Server releases.
Nariman
You are right - distributed cache is really the best way to go.