Quartz Scheduler (2.2.1)-Working with Jobstores

About Job Stores

Jobstores is responsible for keeping track of all the work data you give to the scheduler:jobs, triggers, calendars, and So forth.

Selecting the appropriate jobstore for your Quartz Scheduler instance are an important step. The choice is easy one once you understand the differences between them. Declare which jobstore your scheduler should use (with its configuration settings) in the properties file (or object) t Hat you provide to the schedulerfactory so you use the produce your scheduler instance.

Note: never use a Jobstore instance directly in your code. The Jobstore is to behind-the-scenes use of Quartz itself. You have the Quartz know (through configuration) which jobstore to use. After this, you have work with the Scheduler interface in your code.

Ramjobstore

Ramjobstore is the simplest jobstore to use. It is also offers, the best performance (in terms of CPU time).

A Ramjobstore, as its name indicates, keepsall of it data in RAM. This is why it's lightning-fast and also why it's simple to configure.

The drawback to using Ramjobstore is if your application ends (or crashes), all of the scheduling information I S lost. Therefore, a ramjobstore cannot honor the setting of "non-volatility" on jobs and triggers. For some applications this was acceptable, or even the desired behavior, but for other applications, this may be disastrous .

To use Ramjobstore (and assuming you ' re using stdschedulerfactory) simply set, the ORg.quartz.jobStore.class property T o Org.quartz.simpl.RAMJobStore as illustrated in the example below:

Org.quartz.jobStore.class = Org.quartz.simpl.RAMJobStore

There is no other settings your need to worry.

Jdbcjobstore

Jdbcjobstore keeps all of it data in a database via JDBC. Because it uses a database, it's a bit more complicated to configure than Ramjobstore, and it's not as fast. However, the performance draw-back is not terribly bad, especially if your build the database tables with indexes on the PR Imary keys. On fairly modern set of machines with a decent LAN (between the Scheduler and database) the time to retrieve and update a Firing trigger would typically is less than milliseconds.

Jdbcjobstore works with nearly any database, it had been used widely with Oracle, PostgreSQL, MySQL, MS SQL Server, HSQLDB, and DB2.

To use Jdbcjobstore, you must first create a set of the database tables for Quartz. You can find table-creation SQL scripts in the "Docs/dbtables" directory of the Quartz distribution. If There is not already a script for your database type, just look at one of the existing ones, and modify it on any to n Ecessary for your DB.

Note in the scripts, the tables start with the prefix "Qrtz_" (such as the Tables "Qrtz_triggers", and "qrtz_job_ DETAIL "). This prefix can actually are anything you ' d like, as long as you inform Jdbcjobstore what the prefix are (in your Quartz pro perties). Using different prefixes may is useful for creating multiple sets of tables, for multiple scheduler instances, within the Same database.

Once you has created the tables, you need to decide what type of transactions your application needs. If you don ' t need to tie your scheduling commands (such as adding and removing triggers) to other transactions, then Y ou can let Quartz manage the transaction by using Jobstoretx as your Jobstore (this is the most common selection).

If You need Quartz to work along with other transactions (for example, within a EE application server), you should u Se jobstorecmt, which case Quartz would let the app server container manage the transactions.

Lastly, you must set up a DataSource from which Jdbcjobstore can get connections to your database. DataSources is defined in your Quartz properties using one of a several approaches. One approach is to has Quartz create and manage the DataSource itself by providing all of the connection information for The database. Another approach is to has Quartz use a DataSource that's managed by the application server within which Quartz is Runni Ng. Providing Jdbcjobstore the JNDI name of the DataSource. For details on the properties, consult the example config files in the "Docs/config" folder.

To use Jdbcjobstore (and assuming you ' re using stdschedulerfactory) your first need to set the Jobstore class property of Y Our Quartz configuration to one of the following:

• Org.quartz.impl.jdbcjobstore.JobStoreTx
• Org.quartz.impl.jdbcjobstore.JobStoreCMT

The choice depends on the selection you made based on the explanations in the above paragraphs.

The following example shows how do you configure JOBSTORETX:

Org.quartz.jobStore.class = Org.quartz.impl.jdbcjobstore.JobStoreTX

Next, you need to select a driverdelegate for the jobstore. The driverdelegate is responsible for doing any JDBC work, the May was needed for your specific database.

Stdjdbcdelegate is a delegate this uses "Vanilla" JDBC code (and SQL statements) to do it work. If there isn ' t another delegate made specifically for your database, try the using this delegate. Quartz provides database-specific delegates for databases that does not operate well with stdjdbcdelegate. Other delegates can is found in the Org.quartz.impl.jdbcjobstore package, or with its sub-packages. Other delegates include Db2v6delegate (for DB2 version 6 and earlier), Hsqldbdelegate (for HSQLDB), Mssqldelegate (for Mic Rosoft SQL Server), postgresqldelegate (for PostgreSQL), Weblogicdelegate (for using the JDBC drivers made by WebLogic), Oracle Delegate (for using Oracle), and others.

Once you ' ve selected your delegate, set its class name as the delegate for Jdbcjobstore-use.

The following example shows how do you configure Jdbcjobstore to use a driverdelegate:

Org.quartz.jobStore.driverDelegateClass = Org.quartz.impl.jdbcjobstore.StdJDBCDelegate

Next, you need to inform the Jobstore what table prefix (discussed above) is using.

The following example shows how to configure Jdbcjobstore with the Table Prefix

Org.quartz.jobStore.tablePrefix = Qrtz_

And finally, you need to set which DataSource should is used by the Jobstore. The named DataSource must also is defined in your Quartz properties. In this case, we ' re specifying that Quartz should use the DataSource name "MyDS" (that's defined elsewhere in the Configu Ration properties).

Org.quartz.jobStore.dataSource = MyDS

Tip:if your Scheduler is busy, meaning that's nearly always executing the same number of jobs as the size of the thread Pool, then you should probably set the number of the connections in the DataSource to being the about the size of the thread pool + 2.

Tip:the org.quartz.jobStore.useProperties config parameter can set to TRUE (it defaults to false) in order to instruct Jdbcjobstore that all values in jobdatamaps would be Strings, and therefore can be stored as name-value pairs, rather than Storing more complex objects in their serialized form in the BLOB column. This was much safer in the long term, as you avoid the class versioning issues that come with serializing non-string classe S into a BLOB.

Terracottajobstore

Terracottajobstore provides a means for scaling and robustness without the use of a database. This means your database can is kept free of load from Quartz, and can instead has all of its resources saved for the Res T of your application.

Terracottajobstore can is ran clustered or non-clustered, and in either case provides a storage medium for your job data t Hat is persistent between application restarts, because the data was stored in the Terracotta server. Its performance are much better than using a database via Jdbcjobstore (about an order of magnitude better), but fairly slo Wer than Ramjobstore.

To use Terracottajobstore (and assuming you ' re using stdschedulerfactory) simply set the Org.quartz.jobStore.class Pro Perty toOrg.terracotta.quartz.TerracottaJobStore in your quartz configuration and add one extra property to specify th E Location of the Terracotta server:

Org.quartz.jobStore.class = Org.terracotta.quartz.TerracottaJobStore Org.quartz.jobStore.tcConfigUrl = localhost : 9510

Quartz Scheduler (2.2.1)-Working with Jobstores