Using the JobStoreCMT

2017-11-03 09:05:08

Much of what we said and did in the last several sections for JobStoreTX holds true for the other version of the JDBC JobStore, JobStoreCMT. Again, this shouldn't be all that surprising because both are types of JobStores and are designed to use JDBC to interact with a relational database. Both also extend a common base class.

The JobStoreCMT is designed to participate within the transactional boundaries of a container. This means that the container creates a JTA transaction and makes it available to the JobStore. Quartz's interaction with the JobStore stays within that transaction. If there are any problems, Quartz can signal to the container that it wants the transaction to roll back by calling setRollbackOnly() on the transaction.

Configuring the JobStoreCMT

As with the JobStoreTX and the RAMJobStore before that, the first step in using the JobStoreCMT is to inform the Scheduler of your desire to use the JobStoreCMT. Similar to before, you do this by setting the JobStore class property to the quartz.properties file:

org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreCMT

Be sure to remove the RAMJobStore line if it's present in the properties file.

Configuring the DriverDelegate Class

You also need to choose the DriverDelegate as you did for the JobStoreTX. Quartz relies on a DriverDelegate to communicate with a given database. The delegate is responsible for all communications with the JDBC driver and, thus, the database.

Look back at Table 6.2 for a list of DriverDelegates and choose one based on your database platform and environment. To add the MS SQL Server delegate to the quartz.properties file, add the following line:

org.quartz.jobStore.driverDelegateClass= org.quartz.impl.jdbcjobstore.MSSQLDelegate

You can use several properties to help tune the JobStoreCMT. Table 6.5 shows the entire set.

Table 6.5. The Configuration Properties Available to Be Set for `JobStoreCMT`
Property	Default
`org.quartz.jobStore.driverDelegateClass`
Description: Driver delegates understand the particular dialects of various database systems.
`org.quartz.jobStore.dataSource`
Description: This is the name used in the datasource configuration section of the `quartz.properties` file.
`org.quartz.jobStore.nonManagedTXDataSource`
Description: `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 connectionsin other words, connections for which it is legal for Quartz to directly call `commit()` and `rollback()` on.
`org.quartz.jobStore.tablePrefix`	`QRTZ_`
Description: This is the prefix given to the set of database tables for this Scheduler. Schedulers can use different tables from the same database if the prefixes are different.
`org.quartz.jobStore.useProperties`	`False`
Description: The "use properties" flag instructs the persistent `JobStore` that all values in `JobDataMaps` will be `Strings` and, therefore, can be stored as name-value pairs instead of storing more complex objects in their serialized form in the BLOB column. This is can be handy because you avoid the class-versioning issues that can arise from serializing your non-`String` classes into a BLOB.
`org.quartz.jobStore.misfireThreshold`	`60000`
Description: This is the number of milliseconds the Scheduler will tolerate a trigger to pass its next-fire-time before being considered misfired. The default value (if you don't make an entry of this property in your configuration) is `60000` (60 seconds).
`org.quartz.jobStore.isClustered`	`False`
Description: Set this to true 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.
`org.quartz.jobStore.clusterCheckinInterval`	`15000`
Description: Set the frequency (in milliseconds) at which this instance checks in with the other instances of the cluster. This affects the quickness of detecting failed instances.
`org.quartz.jobStore.maxMisfiresToHandleAtATime`	`20`
Description: This is 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 to hamper the performance of firing other (not yet misfired) triggers.
`org.quartz.jobStore.dontSetAutoCommitFalse`	`False`
Description: 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 if 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)` be called.
`org.quartz.jobStore.selectWithLockSQL`	`SELECT * FROM {0}LOCKS WHERE` `LOCK_NAME = ? FOR UPDATE`
Description: This must be a SQL string that selects a row in the `LOCKS` table and places a lock on the row. If it is not set, the default is `SELECT * FROM {0}LOCKS WHERE LOCK_NAME = ? FOR UPDATE`, which works for most databases. The `{0}` is replaced during runtime with the `TABLE_PREFIX` that you configured earlier.
`org.quartz.jobStore.dontSetNonManagedTX ConnectionAutoCommitFalse`	`False`
Description: This is the same as the property `org.quartz.jobStore.dontSetAutoCommitFalse`, except that it applies to the `nonManagedTXDataSource`.
`org.quartz.jobStore.txIsolationLevelSerializable`	`False`
Description: A value of true tells Quartz (when using `JobStoreTX` or `CMT`) to call `setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE`) on JDBC connections. Th s can be helpful to prevent lock timeouts with some databases under high load and long-lasting transactions.
`org.quartz.jobStore.txIsolationLevelReadCommitted`	`False`
Description: When set to true, this property tells Quartz to call `setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED)` on the nonmanaged JDBC connections. This can be helpful to prevent lock timeouts with some databases (such as DB2) under high load and long-lasting transactions.

Категории