Should I use a Windows Service or an ASP.NET Background Thread?

Question

I am writing a web application in ASP.NET 3.5 that takes care of some basic data entry scenarios. There is also a component to the application that needs to continuously poll some data and perform actions based on business logic.

What is the best way to implement the "polling" component? It needs to run and check the data every couple of minutes or so.

I have seen a couple of different options in the past:

1. The web application starts a background thread that will always run while the web application does. (The implementation I saw started the thread in the Application_Start event.)
2. Create a windows service that is always running

What are the benefits to either of these options? Are there additional options?

I am leaning toward a windows service because it is separated and can run on a different server (more scalable) as well as there is more control over when it is started/stopped, etc. However, I feel like the compactness of having the "background" logic running in the process of the web application might make the entire solution more understandable.

Answer 1

I'd go for the separate Windows service primarily for the reasons you give:

• You can run it on a different server if necessary.
• You can start and stop it independently of the web site.

I'd also add that it could well have some impact on the performance of the web site itself - something you want to avoid.

The buzz-word here is "separation of concerns". The web site is concerned with presenting the data to the user, the service with checking the integrity of the data.

You can also update the web site and service independently of each other should you need to.

I was going to suggest that you look at a scheduled task and let Windows control when the process runs, but I re-read your question and noted that you wanted the checks to run every couple of minutes. The overhead of starting the process might be too great in this case - though some experimentation would probably prove this one way or the other.

There's the possibility that you could start the next check before the current one has finished - something you can code for if you're in complete control.

Answer 2

Why not just use a console app that has no ui? Can do all that the windows service can and is much easier to debug and maintain. I would not do a windows service unless you absolutely have to.

Answer 3

Console application does not do well in this case. I wrote a TAPI application which has to stay in the background and intercept incoming calls. But it did it only once because the tapi manager got GCed and was never available for the second incoming call.

Answer 4

You might find that the SQL Server job scheduler sufficient for what you want.

Answer 5

Hi,

I have a similar scenario. Can you tell me which solution worked best for you.

Thanks