Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Session independant threads. 3

Status
Not open for further replies.

N3XuS

Programmer
Mar 1, 2002
339
BE
hi,
Is there any way to create and start a thread that will finish it's work even when the user logs out or the session expires?

Thanks
 
The answer to your question is yes, but such a thread isn't really very reliable. You can take a look at 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 :p ... 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.

Thanks a lot for your help :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top