Jobs and Triggers
A job is a class that implements the Job interface. As shown below, this interface has one simple method:
package org.quartz;
public interface Job {
public void execute(JobExecutionContext context)
throws JobExecutionException;
}
When a job's trigger fires, the execute(..) method is invoked by one of the Scheduler's worker threads. The JobExecutionContext object that is passed to this method provides the job instance with information about its run-time environment, including a handle to the scheduler that executed it, a handle to the trigger that triggered the execution, the job's JobDetail object, and a few other items.
The JobDetail object is created by the Quartz client (your program) at the time the job is added to the scheduler. This object contains various property settings for the job, as well as a JobDataMap, which can be used to store state information for a given instance of your Job class. The JobDetail object is essentially the definition of the job instance.
Trigger objects are used to trigger the execution (or 'firing') of jobs. When you wish to schedule a job, you instantiate a trigger and 'tune' its properties to provide the scheduling you want to have.
Triggers may also have a JobDataMap associated with them. A JobDataMap is useful for passing to a job parameters that are specific to the firings of the trigger. Quartz ships with a handful of different trigger types, but the most commonly used types are SimpleTrigger and CronTrigger.
SimpleTrigger is handy if you need 'one-shot' execution (just single execution of a job at a given moment in time), or if you need to fire a job at a given time, and have it repeat N times, with a delay of T between executions.
CronTrigger is useful if you wish to have triggering based on calendar-like schedules such as "every Friday, at noon" or "at 10:15 on the 10th day of every month."
Why have both jobs and triggers? Many job schedulers do not have separate notions of jobs and triggers. Some define a 'job' as simply an execution time (or schedule) along with some small job identifier. Others are much like the union of Quartz's Job and Trigger objects. Quartz was designed to create a separation between the schedule and the work to be performed on that schedule. This design has many benefits.
For example, you can create jobs and store them in the job scheduler independent of a trigger. This enables you to associate many triggers with the same job. Another benefit of this loose-coupling is the ability to configure jobs that remain in the scheduler after their associated triggers have expired. This enables you to reschedule them later, without having to re-define them. It also allows you to modify or replace a trigger without having to re-define its associated job.
Identities
Jobs and triggers are given identifying keys when they are registered with the Quartz scheduler. The keys of jobs and triggers (JobKey and TriggerKey) allow them to be placed into 'groups' which can be useful for organizing your jobs and triggers into categories such as "reporting jobs" and "maintenance jobs." The name portion of the key of a job or trigger must be unique within the group. In other words, the complete key (or identifier) for a job or a trigger is the composed of the name and group.
For detailed information about jobs and triggers, see
Jobs and JobDetails and
Working with Triggers.