JDBCJobStore is used to store scheduling information (job, triggers and calendars) within a relational database. There are actually two separate JDBCJobStore classes that you can select between, depending on the transactional behavior you need.

JobStoreCMT relies upon transactions being managed by the application which is using Quartz. A JTA transaction must be in progress before attempt to schedule (or unschedule) jobs/triggers. This allows the work of scheduling to be part of the applications larger transaction. JobStoreCMT actually requires the use of two DataSources. One DataSource has its connection's transactions managed by the application server (via JTA) and one has connections that do not participate in global (JTA) transactions. JobStoreCMT is appropriate when applications are using JTA transactions (such as via EJB Session Beans) to perform their work.

The JobStore is selected by setting the org.quartz.jobStore.class property as such:

JobStoreCMT can be tuned using the following properties:

Driver delegates understand the dialects of various database systems. Possible choices include:

Note that many databases are known to work with the StdJDBCDelegate, while others are known to work with delegates for other databases. Derby, for example, works well with the Cloudscape delegate.

The value of this property must be the name of one the DataSources defined in the configuration properties file. For JobStoreCMT, it is required that this DataSource contains connections that are capable of participating in JTA (i.e., container-managed) transactions. This typically means that the DataSource will be configured and maintained within and by the application server, and Quartz will obtain a handle to it via JNDI. For more information, see DataSource Configuration.

JobStoreCMT requires a (second) DataSource that contains connections that will not be part of container-managed transactions. The value of this property must be the name of one the DataSources defined in the configuration properties file. This DataSource must contain non-CMT connections, or in other words, connections for which it is legal for Quartz to directly call commit() and rollback() on.

JDBCJobStore's tablePrefix property is a string equal to the prefix given to the Quartz tables that were created in your database. You can have multiple sets of Quartz tables within the same database if they use different table prefixes.

The useProperties flag instructs JDBCJobStore that all values in JobDataMaps will 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 is can be handy, as you avoid the class -versioning issues that can arise from serializing your non-String classes into a BLOB.

The number of milliseconds the scheduler will allow a trigger to pass its next-fire-time by before being considered misfired. The default value (if you don't make an entry of this property in your configuration) is 60000 (60 seconds).

Set to true in order to turn on clustering features. This property must be set to true if you are having multiple instances of Quartz use the same set of database tables. Otherwise data corruption and erratic behavior will occur. For more information, see the configuration docs for clustering.

Set the frequency (in milliseconds) at which this instance "checks-in" with the other instances of the cluster. Affects the quickness of detecting failed instances.

The maximum number of misfired triggers the jobstore will handle in a given pass. Handling many (more than a couple dozen) at once can cause the database tables to be locked long enough that the performance of firing other (not yet misfired) triggers may be hampered.

Setting this parameter to true tells Quartz not to call setAutoCommit(false) on connections obtained from the DataSource(s). This can be helpful in a few situations, such as when you have a driver that complains if it is called when it is already off. This property defaults to false, because most drivers require that setAutoCommit(false) is called.

The same as the property org.quartz.jobStore.dontSetAutoCommitFalse except that it applies to the nonManagedTXDataSource.

Must be a SQL string that selects a row in the LOCKS table and places a lock on the row. If not set, the default is "SELECT * FROM {0}LOCKS WHERE SCHED_NAME = {1} AND LOCK_NAME = ? FOR UPDATE." This query string works for most databases. The "{0}" is replaced at run time with the TABLE_PREFIX that you configured above. The "{1}" is replaced with the scheduler's name.

A value of true tells Quartz to call setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE) on JDBC connections. This can be helpful to prevent lock timeouts with some databases under high loads and running long-lasting transactions.

When set to true, this property tells Quartz to call setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED) on the non-managed JDBC connections. This can be helpful to prevent lock timeouts with some databases (such as DB2) under high loads and running long-lasting transactions.

Whether or not the acquisition of next triggers to fire should occur within an explicit database lock. This was once necessary (in previous versions of Quartz) to avoid dead-locks with particular databases, but is no longer considered necessary. Hence the default value is false.

If org.quartz.scheduler.batchTriggerAcquisitionMaxCount is > 1 and JDBC JobStore is used, then this property must be set to true to avoid data corruption (as of Quartz 2.1.1, true is the default when batchTriggerAcquisitionMaxCount is > 1).

The class name to be used to produce an instance of a org.quartz.impl.jdbcjobstore.Semaphore to be used for locking control on the job store data. This is an advanced configuration feature, which should not be used by most users. By default, Quartz will select the most appropriate (pre-bundled) Semaphore implementation to use. "org.quartz.impl.jdbcjobstore.UpdateLockRowSemaphore" QUARTZ-497 may be of interest to MS SQL Server users. "JTANonClusteredSemaphore" which is bundled with Quartz may give improved performance when using JobStoreCMT, though it is an experimental implementation. See QUARTZ-441 and QUARTZ-442.

A pipe-delimited list of properties (and their values) that can be passed to the DriverDelegate during initialization.

The format of the string is as follows:

The StdJDBCDelegate and all of its descendants (all delegates that ship with Quartz) support a property called triggerPersistenceDelegateClasses, which can be set to a comma-separated list of classes that implement the TriggerPersistenceDelegate interface for storing custom trigger types. See the Java classes SimplePropertiesTriggerPersistenceDelegateSupport and SimplePropertiesTriggerPersistenceDelegateSupport for examples of writing a persistence delegate for a custom trigger.