Job Scheduling Considerations

If you are going to be adding job scheduling to your application, then there are a few considerations that you should bear in mind when you choose which scheduler and which approach to take.

Choosing a Scheduler

The first decision you have to make when adding scheduling to your application is which scheduler to use. This is actually quite an easy choice. If you only have very simple scheduling requirements or you are restricted in the external libraries that you can package with your application, then you should use Timer-based scheduling; otherwise use Quartz.

Even if you find that your requirements are simple, you might want to go with Quartz anyway, especially if you have to create an explicit Job implementation. This way, if your requirements become more advanced, you can easily add persistence, transactions, or more complex triggers without having to change a TimerTask to a Job. In general, we have found that using Quartz for all of our scheduling allows us to become familiar with a single scheduling approach and prevents our developers from having to worry about two different approaches, when one provides everything they need.

Package Job Logic Separate from Job Class

A common approach that we see many developers take when they are adding scheduling to an application is to place business logic inside a Job or a TimerTask. Generally, this is a bad idea. In many cases, you also need to have scheduled tasks available for execution on demand, which requires the logic to be separate from the scheduling framework.

Also, you do not need to couple your business logic unduly to a particular scheduler. We have found that a better approach is to keep business logic in separate classes and then either create a simple wrapper around this that is specific to your scheduler or, more preferably, use the appropriate MethodInvoker*FactoryBean to create the wrapper for you.