Discrete .NET middleware processor vs spawning a new process from IIS

Question

I have a 4 tier .NET application which consists of a

• Silverlight 5 Client
• MVC4 Web API Controller (Supplying data to the SL5 Client)
• Windows Service - responsible for majority of data processing.
• Oracle DB storage.

The workflow is simple: SL5 client sends a request to the rest service, the rest service simply stores it in the DB.

The windows service, while periodically polling the DB for new records, detects the new records and attempts to process them accordingly. Once finished it updates the records and their status in the DB.

In the meantime the SL5 Client also periodically polls the DB to see if the records have been processed. When they are, the result is retrieved and rendered on the screen.

So the question here is the following:

1. Is there a difference between spawning the same processing code (currently in the windows service) in a new discrete process (right out of the Web API Controller), vs keeping it as is in the windows service?

Aside from removing the constant DB polling that happens in the windows service, it simplifies processing greatly because it can be done on a per-request basis as the requests arrive from the client. But are there any other drawbacks? Perhaps server or other issues with IIS?

Answer 1

Yes there is a difference.

Windows services are the right tool for asynchronous processing. Operations can take a long time without producing strange effects. After all, it is a continuously running service.

IIS on the other hand, processes requests by using a thread pool. Long running tasks have the potential to exhaust that thread pool, so this may cause problems depending on the number of background tasks you start. Also, IIS makes no guarantees to keep long running tasks alive. If the web site is recycled, which happens regularly in a IIS default installation, your background task may die.