Home Quartz JobStores

JobStores
Posted on: April 13, 2007 at 12:00 AM

Job Store are used to keep track of all the "work data" that you give to the scheduler: jobs, triggers, calendars, etc.

JobStores

Job Store are used to keep track of all the "work data" that you give to the scheduler: jobs, triggers, calendars, etc. The important step for Quartz Scheduler step is selecting the appropriate JobStore. You declare which JobStore your scheduler should use (and it's configuration settings) in the properties file (or object) that you provide to the SchedulerFactory that you use to produce your scheduler instance.

The JobStore is for behind-the-scenes use of Quartz itself. That's why never use JobStore instance directly in you code. Through configuration you have to tell to Quartz which JobStore to use, but then you should only work with the Scheduler interface in your code.

RAMJobStore

RAMJobStore is used to keep all of its data in RAM. That's why it is most performant (lightning fast in terms of CPU time) and simple to configure. The disadvantage is only that at the time of application crashes or ends all of the scheduling information is lost - this means RAMJobStore cannot honor the setting of "non-volatility" on jobs and triggers. In other words, this method's major deficiency is lack of data persistence because it kept all the data in RAM, all information will be lost upon an application or system crash.

Configuring Quartz to use RAMJobStore :

org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

To solve this problem, Quartz offers the JDBCJobStore. This job store keeps all data in a database through JDBC. The trade-off for data persistence is a lower level of performance, as well as a higher level of complexity.

JDBCJobStore

As the name infers, it stores all data in a database via JDBC. That's why it is a little bit more complicated to configure and it is also as faster than RAMJobStore. But the performance deficiency is not terrible bad, especially when you make the database with indexes on the primary keys. The JDBCJobStore is compatible with all major databases, it mostly used with Oracle, MySQL, DB2, MS SQLServer2000.

For using JDBCJobStore your application required two steps. These are follows :

You must create the database tables to be used by the job store. Quartz offers a series of table-creation SQL scripts that ease the setup process. In Quartz distribution ""docs/dbTables" directory you find these SQL scripts. If there is no script according to you database type, the modify the existing ones in any way according to your database. In these scripts all table names start with "QRTZ_" prefix. This prefix can be anything according to your wish, but you have to inform JDBCJobStore what the prefix is (in your Quartz properties). Different prefixes can be useful for creating multiple set of tables, for multiple scheduler instances, within the same database.
org.quartz.jobStore.tablePrefix = QRTZ_(optional, customizable)

You must set the JobStore class properties of your Quartz configuration :

After creating table, you have to decide: what type of transactions you application needs, before configuring & firing up the JDBCJobStore. If your application don't need to tie the scheduling commands like adding trigger and removing trigger, to other transaction, then Quartz manage the transaction by using JobStoreTX as your JobStore.
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
If you need Quartz to work along with other transactions (i.e. within a J2EE application server), then you should use JobStoreCMT - in that case Quartz will let the application server container manage the transactions.
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreCMT
Then select the DriverDelegate for JobStore to use. It is responsible for doing any JDBC work. StdJDBCDelegate is a delegate that uses JDBC code, SQL statements to do its work. Some other delegates are include in the package "org.quartz.impl.jdbcjobstore" and in its sub-packages like DB2v6Delegate, HSQLDelegate, MSSQLDelegate, PostgreSQLDelegate, WeblogicDelegate and OracleDelegate. After selecting the delegate set its class name for JDBCJobStore to use:
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate
JDBCJobStore can get the connections to your database by setting up a DataSource. In Quartz properties DataSource can be defined in different approaches. One approach is, Quartz can create and manage the DataSource itself through providing the all connection information to the database. And another approach is, DataSource is used by Quartz which is managed by an application server that Quartz is running inside of - by providing JDBCJobStore the JNDI name of the DataSource.
org.quartz.jobStore.dataSource = qzDS

If your Scheduler is very busy that means it always executing the same number of jobs as the size of the thread pool, then in the DataSource you should set the number of connections about the size of the thread pool + 1.

Related Tags for JobStores:
c, configuration, interface, jobs, io, instance, int, this, job, config, for, with, work, elf, schedule, scheduler, to, learn, store, self, ld, sh, ear, e, il, it, section, use, ul, art, ce, in, sta, nt, out, j, ace, es, through, dir, hr, ctl, tor, which, s, rect, direct, bst, at, ratio, k, is, ir, ha, ll, lf, ea, du, ar, cod, code, conf, rt, tz, z, scene, sce, s, s, th, sho, av, behind-the-scenes, st, ab, ati, hat, face, nd, only, ode, on, o, nl

«Previous Index Next»