Custom thread started in Application_Start

views:

answers:

+1 Q:

Custom thread started in Application_Start

I have to deal with legacy ASP.NET application written in .NET Framework 1.1. When checking the application code I found interesting part. The application starts custom thread in Application_Start event handler (Global.asax). This thread must run whole life of the application.

Long time ago I read that this should be never used but I don't remember why. What are the problems related to such application design? Is it possible to start thread again when it crashes? Will the crash be logged somewhere automatically (event log)? Can ASP.NET runtime kill the thread for any reason?

At the moment I'm not interested in AppPool recycling. It restarts application, all sessions and creates new thread.

+1 A:

The main problem is that the thread may be terminated at any time by ASP.NET. If the thread's running the whole time, there is presumably some work it should be doing, and getting terminated may not make your application happy the next time it starts up.

Modern solutions include using asynchronous pages and the built-in thread pool.

If you do choose to upgrade, remember that in .NET 1.1, threads throwing a top-level exception just exit; in .NET 2.0, threads throwing a top-level exception crash. If you upgrade, it would probably be better to make the leap to async pages rather than keeping a separate thread.

Stephen Cleary 2010-09-08 15:09:40

This is what I'm affraid of. I know ASP.NET 2.0 handles it threads in thread pool but I'm not sure how it works in ASP.NET 1.1. The thread is actually very important because it handles expired locks in in-memory pesimistic locking. One of the issues I have to solve is that locks are sometimes not released ...

Ladislav Mrnka 2010-09-08 15:14:56

Since the locking is in-memory, it should all be recycled along with the thread when the application restarts. The first thing to determine is if the thread is dying for some unexpected reason; wrap the whole thread procedure in a try/catch and log the error. Reproduce the problem and see what shows up in the log (if anything).

Stephen Cleary 2010-09-08 16:00:15

Yes that is what I'm planing to do. I'm just curious if this is a good practice and what are reasons to not to use it.

Ladislav Mrnka 2010-09-08 18:49:43

+1 The link you posted is really helpful.

Ladislav Mrnka 2010-09-08 18:51:52

It's generally discouraged (modern approaches use async pages). In your *particular* situation, it sounds like it *might* be OK. I would prefer using something like [Session_OnEnd](http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstatemodule.end.aspx) rather than a separate thread.

Stephen Cleary 2010-09-09 19:15:40

ansaurus

tags:

views:

answers:

Custom thread started in Application_Start

related questions