七. 使用 JobStoreTX
我们首先要讨论的持久性 JobStore 是 JobStoreTX。名字中的 "TX" 代表着 "事物"。我们在前面提过，JobStoreTX 是设计用于想要 Quartz 来管理事物的环境中。例如，假如你正构建一个 J2EE 应用，并且不使用到应用服务器，如 WebLogic 或者 JBoss 等，那么 JobStoreTX 会是持久性 JobStore 正确的选择。
在之前章节中，我们看到配置 RAMJobStore 是多么的容易。我们提到 RAMJobStore 的其中一个优点就是易于配置。我们已经讨论过让数据库准备就绪该做的事情；现在我们讲述使 Quartz 应用支持 JDBC JobStore 需要对它配置些什么。
·配置 JobStoreTX
要告诉 Quartz 运行环境你想使用一个别的 JobStore 而不是默认的 RAMJobStore，你必须配置几个属性。配置它们的顺序无关紧要，只要保证在第一次运行程序之前都做了设置。
设置 JobStore 属性
欲告知 Scheduler 应该使用 JobStoreTX，你必须加上下面一行到 quartz.properties 文件中：
org.quartz.jobStore.class = org.quartz.ompl.jdbcjobstore.JobStoreTX
在切换到 JobStoreTX 时确保移动了 RAMJobStore 行(假如存在)。
配置驱动代理
JDBC API 依赖于专属于某个数据库平台的 JDBC 驱动，同样的，Quartz 依赖于某个 DriverDelegate 来与给定数据库进行通信。顾名思义，从 Scheduler 通过 JobStore 对数据库的调用是委托给一个预配置的 DriverDelegate 实例。这个代理承担起所有与 JDBC driver 也就是数据库的通信。
所有的 DriverDelegate 类都继承自 org.quartz.impl.jdbcjobstore.StdDriverDelegate 类。StdDriverDelegte 只有所有代理可用的，平台无关性的基本功能。然而，在不同的数据库平台间还是存在太多的差异，因此需要为某个平台创建特定的代理。表 6.2 列出特定的代理。
| 数据库平台 | Quartz 代理类 |
| Cloudscape/Derby | org.quartz.impl.jdbcjobstore.CloudscapeDelegate |
| DB2 (version 6.x) | org.quartz.impl.jdbcjobstore.DB2v6Delegate |
| DB2 (version 7.x) | org.quartz.impl.jdbcjobstore.DB2v7Delegate |
| DB2 (version 8.x) | org.quartz.impl.jdbcjobstore.DB2v8Delegate |
| HSQLDB | org.quartz.impl.jdbcjobstore.PostgreSQLDelegate |
| MS SQL Server | org.quartz.impl.jdbcjobstore.MSSQLDelegate |
| Pointbase | org.quartz.impl.jdbcjobstore.PointbaseDelegate |
| PostgreSQL | org.quartz.impl.jdbcjobstore.PostgreSQLDelegate |
| (WebLogic JDBC Driver) | org.quartz.impl.jdbcjobstore.WebLogicDelegate |
| (WebLogic 8.1 with Oracle) | org.quartz.impl.jdbcjobstore.oracle.weblogic.WebLogicOracleDelegate |
| Oracle | org.quartz.impl.jdbcjobstore.oracle.OracleDelegate |
|
假如我的数据库平台在表 6.2 中未列出该怎么办？ 如果你的 RDBMS 没在上面列出，那么最好的选择就是，直接使用标准的 JDBC 代理 org.quartz.impl.jdbcjobstore.StdDriverDelegate 就能正常的工作。 |
在你决定好了基于你的数据库平台使用哪个代理，你就需要加入下面的行到 quartz.properties 文件中：
org.quartz.jobStore.driverDelegateClass = <FQN of driver delegate class>
例如，假如你使用 MS SQL Server 作为一你的数据库平台，你就需要加下面这行到属性文件中：
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.MSSQLDelegate
配置数据库表的前缀
前面我们首先讨论 Quartz 要用的数据库表的时候，我们提到所有的表都加有一个前缀 QRTZ_。在某些情况下，你也许需要创建多套的 Quartz 数据库表。在这时候，你就需要改变每一套表的前缀。
表名的前缀配置在 quartz.properties 文件中，使用属性 org.quartz.jobStore.tablePrefix。要改变这一前缀，只要设置这个属性为不同的值：
org.quartz.jobStore.tablePrefix = SCHEDULER2_
确定所有的表名都开始于这一前缀。
|
数据库表和列的命名 假使你还有所疑惑，数据库表的名字(除却前缀) 和表的列名定义在 org.quartz.impl.jdbcjobstore.Constants 接口中。这个接口为 JobStoreSupport 类所实现，因而那些常量值在 JobStoreTX 或 JobStoreCMT 类中是可用的。 |
表 6.3 显示了一系列的属性可用于调节 JobStoreTX。
| 属性 | 默认值 |
| org.quartz.jobStore.driverDelegateClass | |
| 描述：能理解不同数据库系统中某一特定方言的驱动代理 | |
| org.quartz.jobStore.dataSource | |
| 描述：用于 quartz.properties 中数据源的名称 | |
| org.quartz.jobStore.tablePrefix | QRTZ_ |
| 描述：指定用于 Scheduler 的一套数据库表名的前缀。假如有不同的前缀，Scheduler 就能在同一数据库中使用不同的表。 | |
| org.quartz.jobStore.userProperties | False |
| 描述："use properties" 标记指示着持久性 JobStore 所有在 JobDataMap 中的值都是字符串，因此能以 名-值 对的形式存储，而不用让更复杂的对象以序列化的形式存入 BLOB 列中。这样会更方便，因为让你避免了发生于序列化你的非字符串的类到 BLOB 时的有关类版本的问题。 | |
| org.quartz.jobStore.misfireThreshold | 60000 |
| 描述：在 Trigger 被认为是错过触发之前，Scheduler 还容许 Trigger 通过它的下次触发时间的毫秒数(译者注：据原文翻译，真的不好理解，实际效果可参看：http://www.blogjava.net/Unmi/archive/2007/10/23/153413.html 我在评论中的实验)。默认值(假如你未在配置中存在这一属性条目) 是 60000(60 秒)。这个不仅限于 JDBC-JobStore；它也可作为 RAMJobStore 的参数 | |
| org.quartz.jobStore.isClustered | False |
| 描述：设置为 true 打开集群特性。如果你有多个 Quartz 实例在用同一套数据库时，这个属性就必须设置为 true。 | |
| org.quartz.jobStore.clusterCheckinInterval | 15000 |
| 描述：设置一个频度(毫秒)，用于实例报告给集群中的其他实例。这会影响到侦测失败实例的敏捷度。它只用于设置了 isClustered 为 true 的时候。 | |
| org.quartz.jobStore.maxMisfiresToHandleAtATime | 20 |
| 描述：这是 JobStore 能处理的错过触发的 Trigger 的最大数量。处理太多(超过两打) 很快会导致数据库表被锁定够长的时间，这样就妨碍了触发别的(还未错过触发) trigger 执行的性能。 | |
| org.quartz.jobStore.dontSetAutoCommitFalse | False |
| 描述：设置这个参数为 true 会告诉 Quartz 从数据源获取的连接后不要调用它的 setAutoCommit(false) 方法。这在少些情况下是有帮助的，比如假如你有这样一个驱动，它会抱怨本来就是关闭的又来调用这个方法。这个属性默认值是 false，因为大多数的驱动都要求调用 setAutoCommit(false)。 | |
| org.quartz.jobStore.selectWithLockSQL | SELECT * FROM {0}LOCKS WHERE LOCK_NAME = ? FOR UPDATE |
| 描述：这必须是一个从 LOCKS 表查询一行并对这行记录加锁的 SQL 语句。假如未设置，默认值就是 SELECT * FROM {0}LOCKS WHERE LOCK_NAME = ? FOR UPDATE，这能在大部分数据库上工作。{0} 会在运行期间被前面你配置的 TABLE_PREFIX 所替换。 | |
| org.quartz.jobStore.txIsolationLevelSerializable | False |
| 描述：值为 true 时告知 Quartz(当使用 JobStoreTX 或 CMT) 调用 JDBC 连接的 setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE) 方法。这有助于阻止某些数据库在高负载和长时间事物时锁的超时。 | |
本文链接 https://yanbin.blog/quartz-job-scheduling-framework-6-3/, 来自 隔叶黄莺 Yanbin Blog
[版权声明] 
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 进行许可。
您好：
问个问题
如何让quartz不去执行错过的任务
我把org.quartz.jobStore.misfireThreshold设置为1毫秒
它也会执行一次错过的任务，如何让quart根本就不执行错过的任务呢？
很急，现在做的项目用到这点，十分感谢！！