for an example of how to start it. A thread started like that will not be associated with any ASP session, and it will not be allocated from the global thread pool that ASP uses to process page requests.
However, there are a number of caveats here. If you start many of these, the performance of your web server will degrade. These threads won't be associated with an asp.net session, but they sill live inside the asp.net worker process. If that process is recycled or somebody does an IIS reset, your thread will simply die without warning.
A better solution would probably be to create a scheduler application that runs as a windows service in a separate process (there is a visual studio template for creating windows services). That way, you can take advantage of the global thread pool and let it manage the number of active threads for you. It would also be protected from iisresets and recycling of the worker process.
When a web request comes in that requires a new thread, you could create a new record in your database and wait for the service to pick it up.
I was baffled by the fact that my thread kept getting killed when my session ended. I just migrated from IIS 5 to 6 , it used to work in IIS 5. So I checked every single recycle thing, turned on logging on recycling for windows events costed me 10 hours or so ... after many hours - threads really are horrible to debug - I noticed someone programmed the connectionstring to be context dependant, which is gone ofcourse when the session expires.
I never thought of designing it as a service though As you say running it in the asp.net process is far from perfect. It is certainly a very good alternative when it is giving problems again. The thread doesn't run very often though, it just synchronizes customers with ASW when it's triggered.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.