Using the JobStoreCMT

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




Description: Driver delegates understand the particular dialects of various database systems.


Description: This is the name used in the datasource configuration section of the file.


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.



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.



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.



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



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.



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.



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.



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.



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


Description: This is the same as the property org.quartz.jobStore.dontSetAutoCommitFalse, except that it applies to the nonManagedTXDataSource.



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.



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.

Scheduling in the Enterprise

Getting Started with Quartz

Hello, Quartz

Scheduling Jobs

Cron Triggers and More

JobStores and Persistence

Implementing Quartz Listeners

Using Quartz Plug-Ins

Using Quartz Remotely

Using Quartz with J2EE

Clustering Quartz

Quartz Cookbook

Quartz and Web Applications

Using Quartz with Workflow

Appendix A. Quartz Configuration Reference

Quartz Job Scheduling Framework(c) Building Open Source Enterprise Applications
Quartz Job Scheduling Framework: Building Open Source Enterprise Applications
ISBN: 0131886703
EAN: 2147483647
Year: N/A
Pages: 148 © 2008-2020.
If you may any questions please contact us: