I had the opportunity to soapbox recently on the use of cron jobs versus Quartz jobs to handle a task which was to be run on a regular interval.  The task is an application maintenance task.  Periodically, we need to clean out “old” data, so that the system isn’t bogged down by data which is no longer useful. 

My arguments for Quartz were thus: 1) running the regular job within Quartz means that we’ve encapsulated the behavior that the application needs within the bounds of the application itself; 2) that encapsulation also means that we can easily maintain the configuration (how often, when the thing is getting kicked off) within our source code repository; 3) we can easily utilize the same logs, alerts, events, or other infrastructure within the application within our job, and can inject those items using IOC; and 4) Quartz has support for clustering so that multiple machines could handle the load and/or we can have built in fail-over, such that the job doesn’t stop triggering just because one key machine did.  Honestly, my key happy factors are numbers 1 and 2.  I like owning what my app does, and not needing to worry about asking an administrator to look at the cron tables.

Just feeling like a geek post today.