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 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.
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.
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.
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.