Task Scheduler vs Windows Service

It is not uncommon in a project where in we need to schedule some operation. It might be some database call or a webservice call or some simple call to a dll. There are several options one might consider in such a situation.

• Create a Windows Service (background process) with a Timer which would initiate the operation at regular intervals as specified to the Timer.
• Create a task in the Windows Task Scheduler which would initiate the application.
• Create a timer in the global.asax file which would fire at regular intervals to initiate the required operation.
• If the operation is about reading and writing to a SQL database, then SQL CLR integration can also be considered. Here SQL jobs could be used to call a procedure which calls the managed dll.

The project which I worked on required a similar functionality where a scheduler needed to call my dll which in turn would do the required webservice calls and some database operations. Me and my team went through several discussions about which option suits the best for our needs. Following were the highlights of the discussion –:

• Windows Service is a nice option since it has inbuilt logging features and can gracefully handle failures. They are really easy to write ( We were working with .NET). The biggest constraint is writing a scheduler. We needed the operation to occur on a specific day at a specific time. Now we could have written a scheduler with lots of efforts, but if we needed to change the schedule we would have had to change the scheduler parameters somehow. Well a config file can help here but again, it is a technical task and certainly some normal Windows User (non technical) would not know these things by default.
• Windows has a well tested Task Scheduler which can be used to schedule applications to be run at specific intervals. The scheduler is very usable and has pretty good granular control. Although to schedule tasks within seconds once would require to do some trick but we did not want that level of granularity. After rummaging in the cloud we found that once a password of the user Windows account changes, the task needs to be updated with the new credentials. This is kind of an admin task but pretty irritating. Although since with the task scheduler we would be running the application only when needed and not causing a resource hog like a Windows Service. Just to mention though, Windows Task Scheduler is actually implemented as a Service in Windows OS. There are some reports saying that the scheduler is a poorly written application and causes to fail several times.
• A timer in the global.asax file also has the same problem of writing our scheduler. It also causes a needless dependency on the IIS server.
• SQL CLR is a pretty compact option, but me and my team were not completely familiar with writing managed code in SQL and we had to come up with a cheap option in a small time frame.

We finally decided to go with the Windows Task Scheduler. Our application was really simple, it just had few function calls to our core engine which in turn took care of the webservice and database calls. So we did not have much worry about the logging features absent since we could write our own. In turn we got a well tested and easily usable scheduler and an application which ran only when needed.

You can try to find information about such a situation, you would stumble over lots of blogs stating one is better than the other and vice versa. Mostly people have chosen between a Service and the Windows Scheduler, but honestly it depends on the requirements of your application. For few hours I was hanging in limbo, between Service and Windows Scheduler but some of the blogs like Jon Galloway’s blog post helped me make my decision. I state again that our decision of Windows Task Scheduler was based on the information we could gather and our requirements more importantly.

Happy Programming!