Quartz API Operations

Quartz is a Java library, and you may use it to perform job data management and control the scheduler. The central API to the scheduler is the org.quartz.Scheduler interface, and you may get an instance with org.quartz.impl.StdSchedulerFactory.getDefaultScheduler(). You should study this org.quartz.Scheduler interface thoroughly in JavaDoc before using Quartz. When using this API, it is helpful to understand some terms used in regards to Quartz scheduling.

Quartz Client API Operations/Mode

We refer to "client" API when you use org.quartz.Scheduler to manage job data only. Things such as adding, removing, or rescheduling a job, trigger or listeners. These operations can be done on scheduler instance without having it to be started or. Obviously you may also perform job data management while the scheduler is in running mode as well.

Quartz client would use org.quartz.Scheduler instance to perform job data management and then it can exit the JVM process if it choose so. This is specially true if the store is persistence such as the JDBCStore.

Quartz Server API Operations/Mode

We refer to "server" API when you use org.quartz.Scheduler to control the scheduler. You may start, pause or shutdown the scheduler. Note that once a scheduler is shutdown, you can not reuse the instance to re-start it!

We also refer to quartz as "server" mode where scheduler is running with thread pool that execute the jobs once it has started. To keep the server JVM process up and running, the application will usually place the main thread to sleep or wait mode. The Quartz scheduler itself will start other threads to check triggers and execute jobs. This means the "server" should be keep alive and usually run in background.

Note that you can also use Quartz with both "client" and "server" mode in a same process. This is usually the case for small and single JVM scheduler.

Quartz Cluster Operations/Mode

You can configure the Quartz to run in cluster of machine nodes to share a single scheduler data store (eg: JDBCStore). In this case, each node can be a "client" to perform job data management, and each node can be "server" that runs the scheduler. Each running scheduler node will pick up next firing trigger from the cluster store in a random fashion and distribute the work. At this time, Quartz does not have ability to control where a job gets to be executed by a specific node in a cluster of nodes.

In cluster mode, it might be useful to have a dedicated node to as as "client" into the cluster for job data management only. This helps track the application debugging easier with log output etc, and it minimize affect of each running scheduler on the job execution.

Some application may choose to use Quartz Listener that will respond to events and then trigger job data changes. The listeners may be configured to run on each cluster node, and in that moment act as "client". In this case, there is no control over as where and which machine node it will get executed!