Question

Well, I’m sure this is not the first time to see this question. and TBH you can find this question answered on many other websites and blogs -not only here-

But I never saw a complete answer for this question, I mean no one talked about the advantages and the disadvantages. no one shared a real experience.

Although Quartz.NET seems like a good solution but yet, there’s no enough reviews or a good comparison between the different ways to achieve such a thing.

As far as I read about it I found this are the possible ways of doing this :

Using a: Web Service, Windows Appliction, Console Application, Quartz.NET.

Examples of stuff I want to achieve with the scheduled or automatic methods/events are like archiving after a certain period, auto deleting/moving records in the database, setting a property of an object after a certain time, automatically run some methods according to my holiday schedule.

I hope you’d share your experience either with one of those approaches or share a new way of doing this.

Answer 1

At the e-commerce Web site that I work for, we use Quartz.NET in a Windows service called the “Worker”. It executes Quartz.NET IJob implementations via the programmatically-defined schedule and runs independently of the Web site processes. It does things like dispatch e-mails in batches, update statistics, refresh the SOLR indexes, and so on.

This way, we don’t have to worry about our schedules getting reset or missed as a result of worker processes recycling, or dealing with the madness of having multiple instances running simultaneously on the same machine as a result of a Web garden. The Worker is installed, started, and stopped independently of the Web site, and could even exist on a separate machine, giving flexibility in maintenance and deployment.

The Web site and the Worker both share a common Model DLL that contains the object model and NHibernate configuration, so there is not much logical duplication of business logic.

Before I created the Worker/Windows service, I relied on simple console applications that were executed via scheduled tasks. This worked well up to a point, but as the site became more complex and required more and more batch jobs to run periodically, I found myself maintaining a lot of independent console programs and a lot of independent scheduled tasks, which became more difficult as the number of jobs required increased. By consolidating scheduling with Quartz.NET into a single Windows service, I now only have one process to keep an eye on and can be assured that any business logic changes are “in sync” since the model only has to be updated in two places–the Worker and the Web site–instead of many–the Web site and lots of little console applications.

I explored options like storing runtimes in the ASP.NET cache or keeping references around in the worker process’s memory, but I found that (1) this made the exact execution time of the task dependent on incoming requests to the Web site and (2) the use of a Web garden caused unnecessary duplication of effort (since the task would be “scheduled” in multiple worker processes on the same machine).

Creating a Windows service that can be started and stopped via the usual Windows mechanisms has proved to be, in my humble opinion, the most logical, intuitive, and maintainable result in the long run.

Both the Web site and Worker use WiX to compile down to two Windows Installer MSI files, so updating them is a snap–just double-click the MSI on the server, and our update is good to go.

Hope that helps!