Ah, now some specifics... good
I do not understand how the application decides to recycle itself. I
would like to keep these threads alive independent of the frequency of
Request to the web server.
Well, when you create managed threads they're scoped to the AppDomain which
is like a process. The AppDomain in ASP.NET essentially maps to the virtual
directory, meaning all page objects, etc for that vdir live in the AppDomain.
The AppDomain settings are initialized from web.config. So, what causes an
AppDomain to get restarted? Well, changes to web.config for one. Also, based
upon machine.config or IIS configuration, the AppDomain can get restarted
based upon the number of requests to the app, the time the app has been running
and many other things...
I have an aspnet application in a hosted environment. My application
spawns threads that do work in the background. That is to say these
threads do not have HttpContext. I keep handles to these threads by
storing them in my Application object.
So this is cool, it's just that you need to manage this appropriately. I'd
suggest not using the Application object to store this data. Instead use
static (C#) or Shared (VB.NET) data structures to store this data. It's essentially
the same and you don't rely upon a HttpContext for the storage. The big thing
is to clean up these resources when the AppDomain is shutting down. You can
handle the AppDomain.DomainUnload event. Very much the same idea as Application_End,
but again it's not tied to the ASP.NET plumbing. This is where you can do
the cleanup of those handles that you're storeing in static variables.
HTH (and it's 100% google free

)
-Brock
DevelopMentor
http://staff.develop.com/ballen