Quartz - driving the enterprise 'chronometer'

 A job scheduler is a system that is responsible for executing (or notifying) other software components when a pre-determined (scheduled) time arrives.

Quartz is a full-featured, open source job scheduling system that can be integrated with, or used along side virtually any J2EE or J2SE application - from the smallest stand-alone application to the largest e-commerce system. Quartz can be used to create simple or complex schedules for executing tens, hundreds, or even tens-of-thousands of jobs; jobs whose tasks are defined as standard Java components or EJBs. The Quartz Scheduler includes many enterprise-class features, such as JTA transactions and clustering.

 What Can Quartz Do For You?

If your application has tasks that need to occur at given moments in time, or if your system has recurring maintenance jobs then Quartz may be your ideal solution.
Sample uses of job scheduling with Quartz:

• Driving Process Workflow: As a new order is initially placed, schedule a Job to fire in exactly 2 hours, that will check the status of that order, and trigger a warning notification if an order confirmation message has not yet been received for the order, as well as changing the order's status to 'awaiting intervention'.
• System Maintenance: Schedule a job to dump the contents of a database into an XML file every business day (all weekdays except holidays) at 11:30 PM.
• Providing reminder services within an application.

Quartz is distributed as a small java library (.jar file) that contains all of the core Quartz functionality. The main interface (API) to this functionality is the Scheduler interface. It provides simple operations such as scheduling/unscheduling jobs, starting/stopping/pausing the scheduler.

Quartz vs. java.util.Timer

1. Timers have no persistence mechanism.
2. Timers have inflexible scheduling (only able to set start-time & repeat interval, nothing based on dates, time of day, etc.)
3. Timers don't utilize a thread-pool (one thread per timer)
4. Timers have no real management schemes - you'd have to write your own mechanism for being able to remember, organize and retreive your tasks by name, etc.

Runtime environment

• Quartz can run embedded within another free standing application
• Quartz can be instantiated within an application server (or servlet container), and participate in XA transactions
• Quartz can run as a stand-alone program (within its own Java Virtual Machine), to be used via RMI
• Quartz can be instantiated as a cluster of stand-alone programs (with load-balance and fail-over capabilities)

Job Execution

• Jobs can be any Java class that implements the simple Job interface, leaving infinite possibilities for the work your Jobs can perform.
• Job class instances can be instantiated by Quartz, or by your application's framework.
• When a Trigger occurs, the scheduler notifies zero or more Java objects implementing the JobListener and TriggerListener interfaces (listeners can be simple Java objects, or EJBs, or JMS publishers, etc.). These listeners are also notified after the Job has executed.
• As Jobs are completed, they return a JobCompletionCode which informs the scheduler of success or failure. The JobCompletionCode can also instruct the scheduler of any actions it should take based on the success/fail code - such as immediate re-execution of the Job.

Job Persistence

• The design of Quartz includes a JobStore interface that can be implemented to provide various mechanisms for the storage of jobs.
• With the use of the included JDBCJobStore, all Jobs and Triggers configured as "non-volatile" are stored in a relational database via JDBC.
• With the use of the included RAMJobStore, all Jobs and Triggers are stored in RAM and therefore do not persist between program executions - but this has the advantage of not requiring an external database.

 [ For more on features refer: http://www.quartz-scheduler.org/overview/features.html]

Few factors affecting Performance

• RAM-based JobStore is MUCH (1000x) faster than the JDBC-based JobStore.
• Limiting factor of the number of Triggers and Jobs Quartz can "store" and monitor is really the amount of storage space available to the JobStore (either the amount of RAM or the amount of disk space)
• Actual number of jobs that can be running at any moment in time is limitted by the size of the thread pool

Types of Triggers

• SimpleTrigger ALWAYS fires exacly every N seconds, with no relation to the time of day.
• CronTrigger ALWAYS fires at a given time of day and then computes its next time to fire. If that time does not occur on a given day, the trigger will be skipped. If the time occurs twice in a given day, it only fires once, because after firing on that time the first time, it computes the next time of day to fire on.

Scheduling using Quartz
Quartz Implementation with Spring

The Quartz, as we saw above, would be used for 'timing' enterprise activities. This means it would call certain method(s) at certain interval (or certain point of time in a day, month or so). This methods of the particular class & Quartz in general can be wired using Spring IoC.

Example application context xml here under:

HelloClass would be a java class with a method printHallo() (containing System.out.println("Hello mate!"); ).
Misc:

• Quartz in Spring app using Maven build
• Cooking a 'main course' Quartz app?