目录

• 一、配置主调度器设置

• 二、配置ThreadPool设置

• 三、配置全局监听器

• 四、配置Scheduler调度程序插件

• 五、配置RMI设置

• 六、配置RAMJobStore

• 七、配置JDBC-JobStoreTX

• 八、配置JDBC-JobStoreCMT

• 九、配置DataSources

• 十、用JDBC-JobStore配置群集

• 十一、配置TerracottaJobStore

Quartz的配置通常通过使用属性文件（使用StdSchedulerFactory（消耗配置文件并实例化调度程序））来完成。

Quartz-Job的quartz.properties配置文件说明，此文件在quartz的jar包有，可直接拿过来使用不过只有基本的几个配置 自己可根据需要进行扩充；

另外如果项目中没有对该配置文件重写，则Quartz会加载自己jar包中的quartz.properties文件。

或者你也可以在调用StdSchedulerFactory之前调用getScheduler（）时，通过调用其中一个initialize（xx）方法来显式初始化工厂。

文档官网地址：http://www.quartz-scheduler.org/documentation/quartz-2.2.x/configuration/

下面的配置信息是根据蹩脚的Google翻译过来的，如果你的英文不错，移步到官网查看原文自行翻译或许是更好的选择。

jar包中的默认配置如下

# Default Properties file for use by StdSchedulerFactory
# to create a Quartz Scheduler Instance, if a different
# properties file is not explicitly specified.
#

org.quartz.scheduler.instanceName: DefaultQuartzScheduler
org.quartz.scheduler.rmi.export: false
org.quartz.scheduler.rmi.proxy: false
org.quartz.scheduler.wrapJobExecutionInUserTransaction: false

org.quartz.threadPool.class: org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount: 10
org.quartz.threadPool.threadPriority: 5
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread: true

org.quartz.jobStore.misfireThreshold: 60000

org.quartz.jobStore.class: org.quartz.simpl.RAMJobStore

推荐先看一下StdSchedulerFactory.java的源代码是如何配置。以及默认值等。

一、配置主调度器设置

org.quartz.scheduler.instanceName

可以是任何字符串，并且该值对调度程序本身没有意义，而是作为客户端代码在同一程序中使用多个实例时区分调度程序的机制。 如果您正在使用群集功能，则必须对群集中“逻辑上”相同的调度程序的每个实例使用相同的名称。

org.quartz.scheduler.instanceId

可以是任何字符串，但对于所有调度程序来说，必须是唯一的，就像它们在集群中是相同的“逻辑”调度程序一样。 如果希望为您生成Id，则可以使用值“AUTO”作为instanceId。 或者如果你想要这个值来自系统属性“org.quartz.scheduler.instanceId”的值“SYS_PROP”。

org.quartz.scheduler.instanceIdGenerator.class

仅当org.quartz.scheduler.instanceId设置为“AUTO”时才使用。 默认为“org.quartz.simpl.SimpleInstanceIdGenerator”，它根据主机名和时间戳生成实例ID。 其他IntanceIdGenerator实现包括SystemPropertyInstanceIdGenerator（它从系统属性“org.quartz.scheduler.instanceId”获取实例ID，HostnameInstanceIdGenerator使用本地主机名（InetAddress.getLocalHost（），您还可以自己去实现InstanceIdGenerator接口。

org.quartz.scheduler.threadName

可以是java线程的有效名称的任何字符串。 如果未指定此属性，线程将接收调度程序的名称（“org.quartz.scheduler.instanceName”）加上附加的字符串“_QuartzSchedulerThread”。

org.quartz.scheduler.makeSchedulerThreadDaemon

一个布尔值（'true'或'false'），指定调度程序的主线程是否应该是守护线程。 另请参见org.quartz.scheduler.makeSchedulerThreadDaemon属性来调优SimpleThreadPool，如果这是您正在使用的线程池实现（最有可能是这种情况）。

org.quartz.scheduler.threadsInheritContextClassLoaderOfInitializer

一个布尔值（'true'或'false'），用于指定Quartz产生的线程是否会继承初始化线程（初始化Quartz实例的线程）的上下文ClassLoader。 这将影响Quartz主调度线程，JDBCJobStore的失火处理线程（如果使用JDBCJobStore），集群恢复线程（如果使用集群）和SimpleThreadPool中的线程（如果使用SimpleThreadPool）。 将此值设置为“true”可能有助于类加载，JNDI查找以及与应用程序服务器中使用Quartz相关的其他问题。

org.quartz.scheduler.idleWaitTime

在调度程序处于空闲状态时，调度程序将在重新查询可用触发器之前等待的时间量（以毫秒为单位）。 通常，您不必“调整”此参数，除非您使用XA事务，并且在触发器延迟触发时立即出现问题。 不推荐使用小于5000毫秒的值，因为它会导致过多的数据库查询。 小于1000的价值不合法。

org.quartz.scheduler.dbFailureRetryInterval

调度程序在检测到JobStore（例如数据库）之间的连接丢失时，会在重新尝试之间等待的时间量（以毫秒为单位）。 当使用RamJobStore时，此参数显然是没有意义。

org.quartz.scheduler.classLoadHelper.class

默认是最健壮的方法，它是使用“org.quartz.simpl.CascadingClassLoadHelper”类，它依次使用每个其他ClassLoadHelper类，直到一个工作。 您应该可能找不到需要为此属性指定任何其他类，尽管在应用程序服务器中似乎发生了奇怪的事情。 所有当前可能的ClassLoadHelper实现都可以在org.quartz.simpl包中找到。

org.quartz.scheduler.jobFactory.class

要使用的JobFactory的类名。 JobFatcory负责生成JobClasses的实例。 默认值为“org.quartz.simpl.PropertySettingJobFactory”，它只需在类上调用newInstance（）即可在每次执行即将发生时生成一个新的实例。 PropertySettingJobFactory还使用SchedulerContext和Job和Trigger JobDataMaps的内容来反映设置作业的bean属性。

org.quartz.context.key.SOME_KEY

表示将作为字符串放入“调度程序上下文”的名称 - 值对。 （见Scheduler.getContext（））。 所以例如，设置“org.quartz.context.key.MyKey = MyValue”将执行与scheduler.getContext（）等效的put（“MyKey”，“MyValue”）。

除了使用JTA事务之外，事务相关属性应该不在配置文件中。

org.quartz.scheduler.userTransactionURL

应设置为Quartz可以找到Application Server的UserTransaction管理器的JNDI URL。 默认值（如果未指定）为“java：comp / UserTransaction” - 几乎适用于所有应用程序服务器。 Websphere用户可能需要将此属性设置为“jta / usertransaction”。 仅当Quartz配置为使用JobStoreCMT，并将org.quartz.scheduler.wrapJobExecutionInUserTransaction设置为true时才使用此操作。

org.quartz.scheduler.wrapJobExecutionInUserTransaction

如果您希望Quartz在您的工作调用执行之前启动UserTransaction，应设置为“true”。 在作业执行方法完成后，JobDataMap更新后（如果它是StatefulJob），Tx将提交。 默认值为“false”。 您可能还有兴趣在您的作业类上使用@ExecuteInJTATransaction注释，该批注可以控制单个作业，无论Quartz是否应启动JTA事务 - 而此属性会导致所有作业发生。

org.quartz.scheduler.skipUpdateCheck

是否跳过运行快速Web请求以确定是否有可更新的Quartz版本可供下载。 如果检查运行，并且找到更新，则会在Quartz的日志中报告它。 您也可以使用系统属性“org.terracotta.quartz.skipUpdateCheck = true”（可以在系统环境中设置或在java命令行上设置为-D）来禁用更新检查。 建议您禁用生产部署的更新检查。

org.quartz.scheduler.batchTriggerAcquisitionMaxCount

允许调度程序节点一次获取（用于触发）的触发器的最大数量。 默认值为1.数字越大，触发效率越高（在需要很多触发器的情况下需要同时触发） - 但是以群集节点之间可能的不平衡负载为代价。 如果此属性的值设置为> 1，并使用JDBC JobStore，则必须将属性“org.quartz.jobStore.acquireTriggersWithinLock”设置为“true”以避免数据损坏。

org.quartz.scheduler.batchTriggerAcquisitionFireAheadTimeWindow

允许触发器在其预定的火灾时间之前被获取和触发的时间（毫秒）的时间量。

默认值为0.数量越大，触发器触发器的批次获取越有可能一次可以选择和触发超过1个触发器 - 以触发计划为代价不准确地被触发（触发器可能会提早启动该数量）。 在调度程序具有非常大数量的触发器需要在或接近同一时间点触发的情况下，这可能是有用的（为了表现的缘故）。

二、配置ThreadPool设置

org.quartz.threadPool.class

是要使用的ThreadPool实现的名称。 Quartz附带的线程池是“org.quartz.simpl.SimpleThreadPool”，并且应该能够满足几乎每个用户的需求。 它有非常简单的行为，并经过很好的测试。它提供了一个固定大小的线程池，可以计划“live”程序的生命周期。

org.quartz.threadPool.threadCount（线程数）

可以是任何正整数，虽然你应该意识到只有1到100之间的数字是非常实用的。 这是可用于并发执行作业的线程数。 如果你只有几个工作每天发射几次，那么1个线程是很多！ 如果你有成千上万的工作，每分钟都有很多工作，那么你可能希望一个线程数可能更多的是50或100（这很重要，取决于你的工作所执行的工作的性质，以及你的系统资源！）。

org.quartz.threadPool.threadPriority（优先级）

可以是Thread.MIN_PRIORITY（即1）和Thread.MAX_PRIORITY（这是10）之间的任何int。 默认值为Thread.NORM_PRIORITY（5）。

SimpleThreadPool 特定的属性

org.quartz.threadPool.makeThreadsDaemons

可以设置为“true”，使池中的线程创建为守护进程线程。 默认为“false”。 另请参见org.quartz.scheduler.makeSchedulerThreadDaemon属性。

org.quartz.threadPool.threadsInheritGroupOfInitializingThread

可以是“true”或“false”，默认为true。

org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread

可以是“true”或“false”，默认为false。

org.quartz.threadPool.threadNamePrefix

在工作池中的线程名称的前缀将被附加一个数字。

自定义线程池

如果你使用你自己的一个线程池的实现，你可以通过命名属性来简单地设置它上面的属性：

在自定义线程池上设置属性

org.quartz.threadPool.class = com.mycompany.goo.FooThreadPool
org.quartz.threadPool.somePropOfFooThreadPool = someValue

三、配置全局监听器

全局侦听器可以由StdSchedulerFactory实例化和配置，或者您的应用程序可以在运行时自行执行，然后使用调度程序注册侦听器。 “全局”监听器监听每个作业/触发器的事件，而不仅仅是直接引用它们的作业/触发器。

通过配置文件配置侦听器包括给出一个名称，然后指定类名以及要在实例上设置的任何其他属性。 该类必须有一个no-arg构造函数，并且属性被反射设置。 只支持原始数据类型值（包括字符串）。

因此，定义“全局”TriggerListener的一般模式是：

配置全局TriggerListener

org.quartz.triggerListener.NAME.class = com.foo.MyListenerClass
org.quartz.triggerListener.NAME.propName = propValue
org.quartz.triggerListener.NAME.prop2Name = prop2Value

而定义“全局”JobListener的一般模式是：

配置全局JobListener

org.quartz.jobListener.NAME.class = com.foo.MyListenerClass
org.quartz.jobListener.NAME.propName = propValue
org.quartz.jobListener.NAME.prop2Name = prop2Value

四、配置Scheduler调度程序插件

像通过配置文件配置插件的监听器一样，包括给出一个名称，然后指定类名称以及要在实例上设置的任何其他属性。 该类必须有一个no-arg构造函数，并且属性被反射设置。 只支持原始数据类型值（包括字符串）。

因此，定义插件的一般模式是：

配置插件

org.quartz.plugin.NAME.class = com.foo.MyPluginClass
org.quartz.plugin.NAME.propName = propValue
org.quartz.plugin.NAME.prop2Name = prop2Value

Quartz附带了几个插件，可以在org.quartz.plugins包（和子包）中找到。 配置其中几个示例如下：

日志记录触发器历史插件的示例配置

记录触发器历史记录插件捕获触发器事件（它也是一个触发器监听器），然后使用Jakarta Commons-Logging日志记录。 请参阅类的JavaDoc以获取所有可能参数的列表。

日志记录触发器历史插件的示例配置

org.quartz.plugin.triggHistory.class = org.quartz.plugins.history.LoggingTriggerHistoryPlugin
org.quartz.plugin.triggHistory.triggerFiredMessage = Trigger \{1\}.\{0\} fired job \{6\}.\{5\} at: \{4, date, HH:mm:ss MM/dd/yyyy}
org.quartz.plugin.triggHistory.triggerCompleteMessage = Trigger \{1\}.\{0\} completed firing job \{6\}.\{5\} at \{4, date, HH:mm:ss MM/dd/yyyy\}.

XML调度数据处理器插件的示例配置

作业初始化插件从XML文件读取一组作业和触发器，并在初始化期间将其添加到调度程序。 它也可以删除退出的数据。 有关更多详细信息，请参阅该类的JavaDoc。

JobInitializationPlugin的示例配置

org.quartz.plugin.jobInitializer.class = org.quartz.plugins.xml.XMLSchedulingDataProcessorPlugin
org.quartz.plugin.jobInitializer.fileNames = data/my_job_data.xml
org.quartz.plugin.jobInitializer.failOnFileNotFound = true

文件的XML模式定义可以在这里找到：

http://www.quartz-scheduler.org/xml/job_scheduling_data_1_8.xsd

shutdown-hook挂钩插件的示例配置

shutdown-hook插件捕获JVM终止的事件，并在调度程序上调用shutdown。

ShutdownHookPlugin的示例配置

org.quartz.plugin.shutdownhook.class = org.quartz.plugins.management.ShutdownHookPlugin
org.quartz.plugin.shutdownhook.cleanShutdown = true

五、配置RMI设置

不需要任何必要属性，并且都具有“reasonable”默认值。 当通过RMI使用Quartz时，您需要启动Quartz实例，并将其配置为通过RMI“导出”其服务。 然后，您可以通过配置Quartz调度程序将其工作“代理”到服务器来创建客户端到服务器。

某些用户在客户端和服务器之间遇到类可用性（即Job类）的问题。 要解决这些问题，您需要了解RMI的“代码库”和RMI安全管理器。 您可能会发现这些资源有用：

对RMI和代码库的一个很好的描述：http://www.kedwards.com/jini/codebase.html。 重要的一点就是要意识到“代码库”是由客户使用的！

有关安全管理员的快速信息：http://gethelp.devx.com/techtips/java_pro/10MinuteSolutions/10min0500.asp

最后从Java API文档中阅读RMISecurityManager的文档。

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服务将随机选择一个端口，因为调度程序与RMI注册表绑定。

org.quartz.scheduler.rmi.proxy

如果要连接（使用）远程服务的调度程序，则将“org.quartz.scheduler.rmi.proxy”标志设置为true。 您还必须指定RMI注册表进程的主机和端口 - 通常是“localhost”端口1099。

在同一个配置文件中为'org.quartz.scheduler.rmi.export'和'org.quartz.scheduler.rmi.proxy'指定一个'true'值是没有意义的 - 如果你这样做，'export '选项将被忽略。 如果您没有通过RMI使用Quartz，则“export”和“proxy”属性的值“false”当然是有效的。

六、配置RAMJobStore

RAMJobStore用于存储内存中的调度信息（作业，触发器和日历）。 RAMJobStore快速轻便，但是当进程终止时，所有调度信息都会丢失。

通过设置“org.quartz.jobStore.class”属性来选择RAMJobStore：

将计划程序的JobStore设置为RAMJobStore

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

可以使用以下属性调整RAMJobStore：

org.quartz.jobStore.misfireThreshold

在被认为“misfire”错失触发之前，调度程序将“tolerate”一个触发器将其下一个启动时间通过的毫秒数。 默认值（如果您在配置中未输入此属性）为60000（60秒）。

七、配置JDBC-JobStoreTX

JDBCJobStore用于在关系数据库中存储调度信息（作业，触发器和日历）。 实际上，您可以选择两个独立的JDBCJobStore类，具体取决于您需要的事务性行为。

JobStoreTX通过在每次操作（如添加作业）后调用数据库连接上的commit()（或rollback()）来管理所有事务。 如果在独立应用程序中使用Quartz，或者在应用程序不使用JTA事务的情况下，则在Servlet容器中使用JDBCJobStore。

通过设置“org.quartz.jobStore.class”属性来选择JobStoreTX：

将调度程序的JobStore设置为JobStoreTX

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

JobStoreTX可以使用以下属性进行调整：

org.quartz.jobStore.driverDelegateClass

驱动代表了解不同数据库系统的特定“方言”。 可能的选择包括：

• org.quartz.impl.jdbcjobstore.StdJDBCDelegate （完全符合JDBC兼容的驱动程序)

• org.quartz.impl.jdbcjobstore.MSSQLDelegate (对于Microsoft SQL Server和Sybase)

• org.quartz.impl.jdbcjobstore.PostgreSQLDelegate

• org.quartz.impl.jdbcjobstore.WebLogicDelegate (为WebLogic驱动程序)

• org.quartz.impl.jdbcjobstore.oracle.OracleDelegate

• org.quartz.impl.jdbcjobstore.oracle.WebLogicOracleDelegate (对于在Weblogic中使用的Oracle驱动程序)

• org.quartz.impl.jdbcjobstore.oracle.weblogic.WebLogicOracleDelegate (对于在Weblogic中使用的Oracle驱动程序)

• org.quartz.impl.jdbcjobstore.CloudscapeDelegate

• org.quartz.impl.jdbcjobstore.DB2v6Delegate

• org.quartz.impl.jdbcjobstore.DB2v7Delegate

• org.quartz.impl.jdbcjobstore.DB2v8Delegate

• org.quartz.impl.jdbcjobstore.HSQLDBDelegate

• org.quartz.impl.jdbcjobstore.PointbaseDelegate

• org.quartz.impl.jdbcjobstore.SybaseDelegate

请注意，许多数据库已知与StdJDBCDelegate一起工作，而其他数据库与其他数据库的代理人合作，例如Derby与Cloudscape代理（不出意外）工作良好。

org.quartz.jobStore.dataSource（数据源）

此属性的值必须是配置属性文件中定义的数据源的名称。 有关详细信息，请参阅数据源的配置文档。

org.quartz.jobStore.tablePrefix（表前缀）

JDBCJobStore的“表前缀”属性是一个等于在数据库中创建的Quartz表的前缀的字符串。 如果使用不同的表前缀，则可以在同一数据库中拥有多组Quartz表。

org.quartz.jobStore.useProperties

”use properties“标志指示JDBCJobStore，JobDataMaps中的所有值都将是“字符串”，因此可以将其存储为名称 - 值对，而不是以BLOB列的序列化形式存储更复杂的对象。 这可以方便，因为您避免了将非String类序列化为BLOB时可能产生的类版本控制问题。

org.quartz.jobStore.isClustered

设置为“true”以打开群集功能。 如果您有多个Quartz实例使用同一组数据库表，则此属性必须设置为“true”，否则您将遇到破坏。 有关详细信息，请参阅集群配置文档。

org.quartz.jobStore.clusterCheckinInterval

设置此实例“检入”*与群集的其他实例的频率（以毫秒为单位）。 影响检测失败实例的速度。

org.quartz.jobStore.maxMisfiresToHandleAtATime

在给定的通行证中，工作区将处理的最大错误次数触发。 一次处理很多（超过几十打）可能导致数据库表被锁定得足够长，以致可能会阻碍其他（未失败的）触发器触发的性能。

org.quartz.jobStore.dontSetAutoCommitFalse

将此参数设置为“true”可以告诉Quartz在从DataSource获取的连接上不调用setAutoCommit（false）。 这在一些情况下可能会有所帮助，例如，如果您有一个驱动程序，如果它已经关闭时被调用，则会抱怨。 此属性默认为false，因为大多数驱动程序要求调用setAutoCommit（false）。

org.quartz.jobStore.selectWithLockSQL

必须是在“LOCKS”表中选择一行并在该行上放置一个锁的SQL字符串。 如果未设置，默认值为“SELECT * FROM {0} LOCKS WHERE SCHED_NAME = {1} AND LOCK_NAME =？ FOR UPDATE“，适用于大多数数据库。 在运行时使用上面配置的TABLE_PREFIX替换“{0}”。 “{1}”被替换为调度程序的名称。

org.quartz.jobStore.txIsolationLevelSerializable

值“true”表示Quartz（使用JobStoreTX或CMT）在JDBC连接上调用setTransactionIsolation（Connection.TRANSACTION_SERIALIZABLE）。 这可以有助于防止在高负载下的某些数据库的锁定超时以及“持久”事务。

org.quartz.jobStore.acquireTriggersWithinLock

是否在明确的数据库锁中发生触发下一个触发器的触发。 这曾经是必需的（在以前的Quartz版本中），以避免与特定数据库的死锁，但不再需要，因此默认值为“false”。

如果“org.quartz.scheduler.batchTriggerAcquisitionMaxCount”设置为> 1，并使用JDBC JobStore，则此属性必须设置为“true”以避免数据损坏（从Quartz 2.1.1开始，“true”现在是默认值 如果batchTriggerAcquisitionMaxCount设置为> 1）。

org.quartz.jobStore.lockHandler.class

用于生成用于锁定作业存储数据控件的org.quartz.impl.jdbcjobstore.Semaphore实例的类名称。 这是一个高级配置功能，大多数用户不应该使用它。 默认情况下，Quartz将选择最适合（预捆绑）的Semaphore实现来使用。 “org.quartz.impl.jdbcjobstore.UpdateLockRowSemaphore”QUARTZ-497可能对MS SQL Server用户感兴趣。 见QUARTZ-441。

org.quartz.jobStore.driverDelegateInitString

一个以管道分隔的属性列表（及其值），可以在初始化时间内传递给DriverDelegate。

字符串的格式是这样的：

"settingName=settingValue|otherSettingName=otherSettingValue|..."

StdJDBCDelegate及其所有后代（Quartz附带的所有代理）都支持一个名为“triggerPersistenceDelegateClasses”的属性，该属性可以设置为实现用于存储自定义触发器类型的TriggerPersistenceDelegate接口的类的逗号分隔列表。

八、配置JDBC-JobStoreCMT

JDBCJobStore用于在关系数据库中存储调度信息（作业，触发器和日历）。实际上，您可以选择两个独立的JDBCJobStore类，具体取决于您需要的事务性行为。

JobStoreCMT依赖于正在使用Quartz的应用程序管理的事务。在尝试安排（或取消调度）作业/触发器之前，JTA事务必须进行中。这使得调度的“工作”成为应用程序“较大”事务的一部分。 JobStoreCMT实际上需要使用两个数据源，一个是由应用程序服务器（通过JTA）管理的连接的事务，另一个数据源具有不参与全局（JTA）事务的连接。当应用程序使用JTA事务（例如通过EJB会话Bean）来执行其工作时，JobStoreCMT是适当的。

通过设置“org.quartz.jobStore.class”属性来选择JobStore：

将调度程序的JobStore设置为JobStoreCMT

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

JobStoreCMT可以使用以下属性进行调整：

org.quartz.jobStore.nonManagedTXDataSource

JobStoreCMT需要一个（第二个）数据源，其中包含不会是容器管理事务的一部分的连接。 此属性的值必须是配置属性文件中定义的DataSource的名称。 此数据源必须包含非CMT连接，或换句话说，Quartz直接调用commit（）和rollback（）的合法连接。

org.quartz.jobStore.dontSetNonManagedTXConnectionAutoCommitFalse

与属性org.quartz.jobStore.dontSetAutoCommitFalse相同，但它适用于非ManagedTXDataSource。

org.quartz.jobStore.txIsolationLevelReadCommitted

当设置为“true”时，此属性告诉Quartz在非托管JDBC连接上调用setTransactionIsolation（Connection.TRANSACTION_READ_COMMITTED）。 这有助于防止在高负载下的某些数据库（如DB2）和“持久”事务的锁超时。

九、配置DataSources

如果您使用JDBC-Jobstore，则需要使用DataSource（或使用两个DataSource，如果您使用JobStoreCMT）。

DataSources可以通过三种方式进行配置：

1. 在quartz.properties文件中指定的所有池属性，以便Quartz可以自己创建DataSource。

2. 可以指定应用程序服务器管理的Datasource的JNDI位置，以便Quartz可以使用它。

3. 自定义的org.quartz.utils.ConnectionProvider实现。

建议您将Datasource max连接大小配置为至少线程池中的工作线程数量加上三个。 如果您的应用程序也频繁调用调度程序API，则可能需要其他连接。 如果您使用JobStoreCMT，则“非受管理”数据源的最大连接大小应至少为4。

您定义的每个DataSource（通常为一个或两个）必须为一个名称，并且您为每个定义的属性必须包含该名称，如下所示。 DataSource的“NAME”可以是任何您想要的，除了能够在分配给JDBCJobStore之后能够识别它之外，没有什么意义。

Quartz创建的DataSource使用以下属性定义：

org.quartz.dataSource.NAME.driver

必须是数据库的JDBC驱动程序的java类名称。

org.quartz.dataSource.NAME.URL

连接到数据库的连接URL（主机，端口等）。

org.quartz.dataSource.NAME.user

连接到数据库时要使用的用户名。

org.quartz.dataSource.NAME.password

连接到数据库时要使用的密码。

org.quartz.dataSource.NAME.maxConnections

DataSource可以在其连接池中创建的最大连接数。

org.quartz.dataSource.NAME.validationQuery

是可选的SQL查询字符串，DataSource可用于检测和替换失败/损坏的连接。

例如，oracle用户可能会选择“从user_tables中选择table_name” - 这是一个不应该失败的查询 - 除非连接实际上是坏的。

org.quartz.dataSource.NAME.idleConnectionValidationSeconds

空闲连接测试之间的秒数 - 仅在设置验证查询属性时启用。

默认值为50秒。

org.quartz.dataSource.NAME.validateOnCheckout

每次从池中检索连接时，是否应该执行数据库sql查询来验证连接，以确保它仍然有效。 如果为假，则在办理登机手续时将进行验证。 默认值为false。

org.quartz.dataSource.NAME.discardIdleConnectionsSeconds

它们在空闲之后放弃连接几秒钟。 0禁用该功能。 默认值为0。

Quartz定义的DataSource示例

org.quartz.dataSource.myDS.driver = oracle.jdbc.driver.OracleDriver
org.quartz.dataSource.myDS.URL = jdbc:oracle:thin:@10.0.1.23:1521:demodb
org.quartz.dataSource.myDS.user = myUser
org.quartz.dataSource.myDS.password = myPassword
org.quartz.dataSource.myDS.maxConnections = 30

对Application Server数据源的引用使用以下属性定义：

org.quartz.dataSource.NAME.jndiURL

由应用程序服务器管理的DataSource的JNDI URL。

org.quartz.dataSource.NAME.java.naming.factory.initial

使用的JNDI InitialContextFactory的（可选）类名。

org.quartz.dataSource.NAME.java.naming.provider.url

用于连接到JNDI上下文的（可选）URL。

org.quartz.dataSource.NAME.java.naming.security.principal

（可选的）用户主要用于连接到JNDI上下文。

org.quartz.dataSource.NAME.java.naming.security.credentials

用于连接到JNDI上下文的（可选）用户凭据。

从应用程序服务器引用的数据源示例

org.quartz.dataSource.myOtherDS.jndiURL=jdbc/myDataSource
org.quartz.dataSource.myOtherDS.java.naming.factory.initial=com.evermind.server.rmi.RMIInitialContextFactory
org.quartz.dataSource.myOtherDS.java.naming.provider.url=ormi://localhostorg.quartz.dataSource.myOtherDS.java.naming.security.principal=admin
org.quartz.dataSource.myOtherDS.java.naming.security.credentials=123

自定义ConnectionProvider实现

org.quartz.dataSource.NAME.connectionProvider.class

要使用的ConnectionProvider的类名。 实例化之后，Quartz可以自动设置实例上的配置属性，bean样式。

使用自定义ConnectionProvider实现的示例

org.quartz.dataSource.myCustomDS.connectionProvider.class = com.foo.FooConnectionProvider
org.quartz.dataSource.myCustomDS.someStringProperty = someValue
org.quartz.dataSource.myCustomDS.someIntProperty = 5

十、用JDBC-JobStore配置群集

Quartz的集群功能通过故障转移和负载平衡功能为您的调度程序带来高可用性和可扩展性。

目前，群集仅适用于JDBC-Jobstore（JobStoreTX或JobStoreCMT），并且基本上通过使群集的每个节点共享相同的数据库来工作。

负载平衡自动发生，群集的每个节点都尽可能快地触发作业。当触发器的触发时间发生时，获取它的第一个节点（通过在其上放置一个锁定）是将触发它的节点。

每次射击只能有一个节点开火。我的意思是，如果工作有一个重复的触发器，告诉它每10秒钟发射一次，那么在12:00:00，正好一个节点将运行这个工作，在12:00:10，一个节点将运行作业等。它不一定是每次相同的节点 - 它或多或少是随机的，哪个节点运行它。负载平衡机制对于繁忙的调度器（大量的触发器）是近乎随机的，但是对于非忙（例如，很少的触发器）调度器而言，有利于相同的节点。

当其中一个节点在执行一个或多个作业期间失败时发生故障切换。当节点出现故障时，其他节点会检测到该状况并识别数据库中在故障节点内正在进行的作业。

任何标记为恢复的作业（在JobDetail上都具有“请求恢复”属性）将被剩余的节点重新执行。没有标记为恢复的作业将在下一次相关的触发器触发时简单地被释放以执行。

集群功能最适合扩展长时间运行和/或cpu密集型作业（通过多个节点分配工作负载）。如果您需要扩展以支持数千个短时运行（例如1秒）作业，则可以考虑通过使用多个不同的调度程序（包括HA的多个群集调度程序）对作业集进行分区。调度程序使用集群范围的锁，这种模式会在添加更多节点（超过三个节点 - 取决于数据库的功能等）时降低性能。

通过将“org.quartz.jobStore.isClustered”属性设置为“true”来启用聚类。集群中的每个实例都应该使用相同的quartz.properties文件。这样做的例外是使用相同的属性文件，具有以下允许的异常：不同的线程池大小，以及“org.quartz.scheduler.instanceId”属性的不同值。集群中的每个节点必须具有唯一的instanceId，通过将“AUTO”作为此属性的值，可以轻松完成（不需要不同的属性文件）。有关更多信息，请参阅有关JDBC-JobStore的配置属性的信息。

不要在单独的机器上运行群集，除非它们的时钟使用某种形式的时间同步服务（守护进程）进行同步，而这些时间同步服务（守护进程）运行非常有限（时钟必须在彼此之间）。 如果您不熟悉如何执行此操作，请参阅http://www.boulder.nist.gov/timefreq/service/its.htm。

不要针对任何其他实例运行（start（）ed）的同一组数据库表启动（scheduler.start()）非集群实例。 您可能会收到严重的数据损坏，一定会遇到不正常的行为。

集群调度程序的示例属性

#============================================================================
# Configure Main Scheduler Properties  
#============================================================================

org.quartz.scheduler.instanceName = MyClusteredScheduler
org.quartz.scheduler.instanceId = AUTO

#============================================================================
# Configure ThreadPool  
#============================================================================

org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 25
org.quartz.threadPool.threadPriority = 5

#============================================================================
# Configure JobStore  
#============================================================================

org.quartz.jobStore.misfireThreshold = 60000

org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.oracle.OracleDelegate
org.quartz.jobStore.useProperties = falseorg.quartz.jobStore.dataSource = myDS
org.quartz.jobStore.tablePrefix = QRTZ_

org.quartz.jobStore.isClustered = trueorg.quartz.jobStore.clusterCheckinInterval = 20000

#============================================================================
# Configure Datasources  
#============================================================================

org.quartz.dataSource.myDS.driver = oracle.jdbc.driver.OracleDriver
org.quartz.dataSource.myDS.URL = jdbc:oracle:thin:@polarbear:1521:dev
org.quartz.dataSource.myDS.user = quartz
org.quartz.dataSource.myDS.password = quartz
org.quartz.dataSource.myDS.maxConnections = 5
org.quartz.dataSource.myDS.validationQuery=select 0 from dual

十一、配置TerracottaJobStore

TerracottaJobStore用于在兵马俑服务器内存储调度信息（作业，触发器和日历）。

TerracottaJobStore比使用数据库来存储调度数据（通过JDBC-JobStore）要好得多，而且提供了诸如负载平衡和故障转移之类的集群功能。

您可能需要考虑如何设置Terracotta服务器的影响，特别是启用功能的配置选项，例如在磁盘上存储数据，使用fsync以及运行一系列的Terracotta服务器。

集群功能最适合扩展长时间运行和/或cpu密集型作业（通过多个节点分配工作负载）。如果您需要扩展以支持数千个短期运行（例如1秒）作业，请考虑使用多个不同的调度程序对作业集进行分区。使用多个调度程序当前强制使用集群范围的锁，这是一种在添加更多客户端时降低性能的模式。

有关此JobStore和Terracotta的更多信息，请访问http://www.terracotta.org/quartz

通过设置“org.quartz.jobStore.class”属性来选择TerracottaJobStore：

将计划程序的JobStore设置为TerracottaJobStore

  org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore

TerracottaJobStore可以使用以下属性进行调整：

org.quartz.jobStore.tcConfigUrl

主机和端口标识要连接的Terracotta服务器的位置，例如“localhost：9510”。

未经允许请勿转载：程序喵 » Quartz 定时任务使用 —— quartz.properties的配置（十六）