One of my favorite, often least used, open source tools for Java/J2EE applications is the Cron Job scheduling tool Quartz. Anyone who’s ever administered Linux or a web server is probably familiar with creating and modifying cron jobs to run a process at a specific time of the day/week/month. For example, you may need a nightly clean job for a data directory, or you may need to generate reports automatically at the end of the week. What I like about Quartz is that it’s simple to use, works in both Java and J2EE server-based applications, and is easy to install.
Java with operating-system cron jobs
Despite the availability of Quartz and similar Java-based tools, some developers still choose to use the operating system crontab and set it up to call Java methods directly. Although this can work well in practice, it’s not a very stable solution. For example, if the Java home variable changes, the cron job could break. Also, it’s not portable, since each operating system has a slightly different scheduling tool. Most importantly, though, the application is more vulnerable to attack since it requires input from a process outside the JVM.
What is Quartz?
Quartz is an open source scheduling module written entirely in Java, which lives inside the JVM. It has complete support for creating jobs based on crontab-like syntax, such as using the string “0 4 * * * ?” to run a job every day at 4am. It also supports a more rigorous non-crontab syntax for schedules that can’t be specified in a single string. Anytime a developer needs to write a process that runs in the background, whether its run once a day or every 5 minutes, they should consider Quartz for their scheduling needs.
Creating a Job
Even though you probably only have one job you want to schedule, all Quartz applications start by creating a scheduler that can support any number of jobs using the following code:
SchedulerFactory schedulerFactory = new org.quartz.impl.StdSchedulerFactory(); Scheduler scheduler = schedulerFactory.getScheduler(); scheduler.start();
From there, we can create our 4am job schedule by defining the job, defining the schedule, and then tying the two together by adding them to our scheduler instance, as below:
JobDetail job = new JobDetail("myJob",MyClass.class);
CronTrigger schedule = new CronTrigger("mySchedule",Scheduler.DEFAULT_GROUP,"0 4 * * * ?");
scheduler.scheduleJob(job,schedule);
Finally, you create a job class, in this case MyClass, that implements the Job interface and has a method quite similar to a main method:
public class MyClass implements Job {
public void execute(JobExecutionContext context) {
... // Perform job
}
}
Keep in mind that this code to create the scheduler and job can be in any class. The only class-level restriction is that the job itself has to implement the Job interface. How and where the job is created is up to you.
J2EE: How to apply?
J2EE servers often run for long periods of time, therefore they are a natural fit for Quartz scheduling. For example, you can use Quartz to create reports out of large sets of data in the middle of the night when usage is low. There are literally dozens of ways to integrate Quartz with J2EE, but the two main ways I prefer to use are:
- Job calls a session bean method
- Job creates a message and sends it to a JMS queue
In both cases, the job itself is *never* more than a page of code. It just picks up what it was called for and executes a J2EE call. In this manner, you might have a bean called ReportBean with a method on the bean call generateNightlyReport(). The Quartz job would be a short segment of code that connects to the bean and executes the session bean command.
My favorite method, though, is to have a job create a message and send it to a JMS queue, since the Quartz process can return without waiting for the actual job to finish. Also, the job does not require a transaction or context since it’s going to a queue instead of executing a bean directly. As long as you have a messaging bean watching the queue, the job will get executed soon after the Quartz scheduler has finished processing the request.
Some tips
Hopefully this article has given you a taste for Quartz as a scheduling tool. While I am aware there are other scheduling tools in Java, Quartz has always worked right out of the box for me with very little effort, so to be honest I’ve never had a reason to try another. Here are some tips I recommend to write good Quartz applications:
- Keep your job class under a page. If you find yourself writing a very large job class, extract the useful code into a separate class and have the job code call that class. In this manner, there’s very little code actually tied to your scheduler and you can reuse the class outside the context of scheduler.
- If your schedule executes often or your jobs are quite long, there’s the distinct possibility a job could be started while the last job is running. For example, if a job runs every 2 minutes and the first job is taking 3 minutes, Quartz won’t block the second job from starting so you will have multiple instances of the same job running at once. While there are probably ways to prevent this within Quartz, one sanity check I like to enforce is a semaphore lock that prevents two threads from executing the same code at the same time. In the case a second job is started while the first is running, the second should just exit instead of waiting for the first to finish. In Java, you can do this atomically by setting an int to 0 or 1.
- Quartz is often included in a number of J2EE server packages, so you may have it without the need to import the libraries. Keep in mind, though, that the existing version installed with the J2EE server may be older than the one you want to use. In that case, you may want to import your own Quartz jar into the application.