Quartz配置参考

org.quartz.scheduler.rmi.export

如果你想要让Quartz Scheduler通过RMI导出，那么需要将rmi.export标志为true。

org.quartz.scheduler.rmi.registryHost

可以找到RMI注册表的主机(通常为localhost)。

org.quartz.scheduler.rmi.registryPort

RMI注册表监听的端口(通常为1099)。

org.quartz.scheduler.rmi.createRegistry

根据你想要Quartz如何创建RMI注册表，来设置rmi.createRegistry标志。如果你不想让Quartz创建注册表（已经有一个外部的注册表在运行），那么就用false或never。如果你想要让Quartz第一次尝试使用已有的注册表，然后创建一个，就设置为true或则as_needed。如果你想要Quartz尝试创建一个注册表，然后使用它，那么就设置为always。如果已经创建了，它会绑定到org.quartz.scheduler.rmi.registryPort指定的端口上，org.quartz.rmi.registryHost应该为localhost。

org.quartz.scheduler.rmi.serverPort

Quartz Scheduler服务绑定和监听连接的端口。默认情况下，RMI服务会随机选择一个端口将scheduler绑定到RMI注册表。

org.quartz.scheduler.rmi.proxy

如果你想要连接到远端提供服务的scheduler，那么将org.quartz.scheduler.rmi.proxy标志设置为true。你也必须为RMI注册表指定一个主机和端口，通常为localhost和1099。

注意，在同一个配置文件中，将org.quartz.scheduler.rmi.export和org.quartz.scheduler.rmi.proxy都设置为true是没有意义的。如果你这样做了，那么export选项就会被忽略。如果export和proxy属性都是false当然是合法的，如果你不使用RMI的话。

6 配置RAMJobStore

RAMJobStore用于在内存里存储调度信息(job、triggers和calendar)。RAMJobStore快速且轻量，但是当进程终止时所有调度信息会丢失。

选择RAMJobStore的话，需要这样设置org.quartz.jobStore.class属性：

设置Scheduler的JobStore为RAMJobStore

org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

RAMJobStore可以调整以下参数：

org.quartz.jobStore.misfireThreshold

trigger被认为失败之前，scheduler能够承受的下一次触发时间（单位毫秒）。默认值为60秒。

7 配置JDBC-JobStoreTX

JDBCJobStore用于将调度信息（job、trigger和calendar）存储到关系数据库中。实际上有两种JDBCJobStore类供选择，依赖于你需要的事务行为。

在每一个动作之后（例如添加一个job），JobStoreTX通过调用commit()方法或者rollback()方法管理所有数据库连接的事务。如果你是在独立的应用中使用或者在Servlet容器里没有使用JTA事务，那么JDBCJobStore是合适的。

选择JobStoreTX的话，需要这样设置org.quartz.jobStore.class属性：

设置Scheduler的JobStore为JobStoreTX

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

JobStoreTX可以调整以下参数：

org.quartz.jobStore.driverDelegateClass

Driver代理直到各种数据库系统的方言。可能的选择包括：

1. org.quartz.impl.jdbcjobstore.StdJDBCDelegate(完全兼容JDBC的驱动)
2. org.quartz.impl.jdbcjobstore.MSSQLDelegate(Microsoft SQL Server和Sybase)
3. org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
4. org.quartz.impl.jdbcjobstore.weblogicDelegate(WebLogic驱动)
5. org.quartz.impl.jdbcjobstore.oracle.OracleDelegate
6. org.quartz.impl.jdbcjobstore.oracle.WebLogicOracleDelegate(Weblogic使用的Oracle驱动)
7. org.quartz.impl.jdbcjobstore.oracle.weblogic.WebLogicOracleDelegate(Weblogic使用的Oracle)
8. org.quartz.impl.jdbcjobstore.CloudscapeDelegate
9. org.quartz.impl.jdbcjobstore.DB2v6Delegate
10. org.quartz.impl.jdbcjobstore.DB2v7Delegate
11. org.quartz.impl.jdbcjobstore.DB2v8Delegate
12. org.quartz.impl.jdbcjobstore.HSQLDBDelegate
13. org.quartz.impl.jdbcjobstore.Pointbasedelegate
14. org.quartz.impl.jdbcjobstore.SybaseDelegate

注意许多数据库都能与StdJDBCDelegate一起工作，而其它的数据库也能与其它的数据库代理一起动作。例如,Derby就可以使用Cloudscape代理（不惊讶）。

org.quartz.jobStore.dataSource

这个属性的值必须是配置属性文件中定义的DataSource的名字。参见配置DataSource了解更多信息。

org.quartz.jobStore.tablePrefix

JDBCJobStore的表前缀属性是一个字符串，等于数据库中数据表的前缀。如果表前缀不同，那么在同一个数据库中可以创建多个数据表。

org.quartz.jobStore.useProperties

“org.quartz.jobStore.useProperties”配置参数可以被设置为true（默认为false），这样可以指导JDBCJobStore，JobDataMaps中的值都是字符串，因此这样可以以名字-值对存储，而不是存储更加复杂的对象（序列化形式BLOB）。从长远来看，这是很安全的，因为避免了将非字符串类序列化为BLOB的类版本问题。

org.quartz.jobStore.misfireThreshold

Scheduler认为trigger能够承受的下一次触发失败时间（单位毫秒）。默认值为60秒。

org.quartz.jobStore.isClustered

使用集群特性，这个属性必须为true。如果你有多个Quartz实例使用相同的数据库表，这个属性必须为true，否则你会体验一把大破坏。参见集群配置。

org.quartz.jobStore.clusterCheckinInterval

设置当前实例check in集群中其它实例的频率。影响检测到故障实例的速度。

org.quartz.jobStore.maxMisfiresToHandleAtATime

JobStore处理失败trigger的最大等待时间。同时处理多个trigger（多于几个）回引发数据表长时间锁定，触发其它的trigger（还没有失败）的性能就会受到限制。

org.quartz.jobStore.dontSetAutoCommitFalse

将这个参数设置为true，就是告诉Quartz不要调用DataSource获取的连接的setAutoCommit(false)方法。这对某些场景是有帮助的，例如如果一个驱动已经关闭了，你调用它，它就会抱怨。这个属性默认为false，因为大多数驱动都会调用setAutoCommit(false)方法。

org.quartz.jobStore.selectWithLockSQL

必须是一个字符串，在LOCKS表中选择一行，然后再这一行放一把锁。默认为“SELECT * FROM {0}LOCKS WHERE SCHED_NAME = {1} AND LOCK_NAME = ? FOR UPDATE”，这对于大多数数据库都适用。“{0}”由上面的配置的TABLE_PREFIX在运行时替换，而“{1}”由scheduler的名字替换。

org.quartz.jobStore.txIsolationLevelSerializable

如果值为true，就是告诉Quartz（当使用JobStoreTX或CMT)调用JDBC连接的setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE)方法。这可以防止在高负载、持久事务时锁定超时。

org.quartz.jobStore.acquireTriggersWithinLock

是否在数据库锁内获取下一个要触发的trigger。在之前的Quartz版本中，为避免死锁必须用它，但是现在不再是必要了，一次默认值为false。

如果“org.quartz.scheduler.batchTriggerAcquisitionMaxCount”的值大于1，且使用了JDBC JobStore，那么这个属性必须设置true，以避免数据损坏。在Quartz 2.1.1中，如果batchTriggerAcquisitionMaxCount大于1，那么默认值就是true。

org.quartz.jobStore.lockHandler.class

用这个类名生成一个org.quartz.impl.jdbcjobstore.Semaphore实例，用于锁定控制JobStore的数据。这是一个高级配置特性，大多数用户不应该使用它。默认情况下，Quartz会选择最合适的Semaphore实现。MS SQL Server用户可能会对“org.quartz.impl.jdbcjobstore.UpdateLockRowSemaphore”感兴趣。

org.quartz.jobStore.driverDelegateInitString

由“|”分割的属性（和它们的值），在初始化时，传递给DriverDelegate。

字符串的格式类似于：

“settingName=settingValue|otherSettingName=otherSettingValue|...“

StdJDBCDelegate和它所有的子类(Quartz自带的所有代理类)支持一个属性叫“triggerpersistenceDelegateClasses”，可以被设置为逗号（,）分割的类，它们实现了TriggerPersistenceDelegate接口，用于存储自定义的trigger类型。参见SimplePropertiesTriggerPersistenceDelegateSupport类以及编写定义trigger的持久化代理示例。

8 配置JDBC-JobStoreCMT

JobStoreCMT依赖于使用Quartz的应用管理的事务。JTA事务必须在尝试调度（取消调度）job和trigger之前处于运行中。这允许调度工作作为更大事务的一部分。JobStoreCMT实际上需要两种数据源，一种是应用服务器管理它的连接事务（通过JTA），另一种是它有连接埠参与全局事务。当应用使用JTA事务（例如通过EJB回话Bean）执行工作时，JobStoreCMT是合适的。

选择RAMJobStore的话，需要这样设置org.quartz.jobStore.class属性：

设置Scheduler的JobStore为JobStoreCMT

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

JobStoreCMT可以调整的参数如下：

org.quartz.jobStore.dataSource

这个属性的值必须是配置文件中DataSource的名字。对于JobStoreCMT，要求这个数据源包含的连接要能参与JTA事务。这意味着DataSource是由应用服务器配置和维护的，Quartz只是通过JNDI引用它。

org.quartz.jobStore.nonManagedTXDataSource

JobStoreCMT需要第二个数据源，它包含一些不受容器管理的事务。这个属性的值必须是配置文件中DataSource的名字。这个数据源必须包含非CMT连接。换句话说，它的连接杜宇Quartz来说调用commit和rollback方法是合法的。

org.quartz.jobStore.dontSetNonManagedTXConnectionAutoCommitFalse

与org.quartz.jobStore.dontSetAutoCommitFalse属性一样，只是它适用于nonManagedTXDataSource。

org.quartz.jobStore.lockHandler.class

Quartz自带的“JTANonClusteredSemaphore”提高了不少性能，虽然它是一个实验实训。

其它配置同JobStoreTX

9 配置DataSource