[译]Quartz 2.2.x 第九课 JobStores

JobStore是负责跟踪调度器中的所有工作数据：作业，触发器，日历等。为你的调度器实例选择一个合适的JobStore是一件非常重要的步骤。幸运地是，一旦你理解了不同JobStore之间的区别，那么选择是一个合适的JobStore很容易的事情。你可以在配置文件（或是类对象中）定义调度器使用哪种JobStore，这个JobStore会提供给ScheduleFacotory用来创建你的调度器实例。

我们不建议你在代码中直接使用JobStore，虽然一些开发者出于某些原因尝试这么做。JobStore是在Quartz幕后使用的，因此你只需要配置信息来告诉Quartz使用哪个JobStore就行了，然后在代码中应该直接调用接口即可。

RAMJobStore

 RAMJobStore是最容易使用的JobStore，它也是最高效的（从CPU时间计算）。从RAMJobStore的名字可以明显地发现：它将

所有数据存储在RAM中。这就是为什么它速度快并且配置简单的原因。缺点是当你的应用终止（或是崩溃）时，所有的调度信息都会

丢失——这意味着RAMJobStore会导致作业任务和触发器的non-volatility设置不起作用。对某些应用来说，这种缺点可以接受，甚至

需要这样的特性，但对另外一些应用来说，这种缺点可能会成为一个灾难。
       假定你正在使用StdSchedulerFactory，想要使用RAMJobStore时，只需要在Quartz配置文件中将JobStore class参数的值指定为

org.quartz.simpl.RAMJobStore的类全名即可：

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

这里就没有什么其他设置可以操心了啦！

JDBCJobStore

JDBCJobStore同样人如其名——它通过JDBC将所有的数据保存在数据库中。正因为如此配置JDBCJobStore要比RAMJobStore复杂许多，并且也没RAMJobStore速度快。然而，后台的执行效率也不是非常糟糕，特别是如果你在数据库的主键中创建索引，就可以提高效率。比较好的局域网环境内的现代标准配置的机器，恢复和更新一个触发器所需要花费的时间一般在10毫秒以内。

         JDBCJobStore几乎可以适用于任何数据库，它已经在Oracle,PostgreSQL, MySQL, MS SQLServer, HSQLDB和 DB2数据库中广泛使用。为了使用JDBCJobStore，你必须先创建一套数据库表供Quartz使用。你可以在Quartz发布包的“docs/dbTables”目录找到建表SQL脚本。如果现成的脚本不适合你的数据库类型，找到其中一个脚本，想尽一切必要的方法修改成适合你的数据库。需要注意一点是在这些脚本中，所有表的前缀都是“QRTZ_”（例如表“QRTZ_TRIGGERS”和“QRTZ_JOB_DETAIL”）。这个前缀实际上可以是任何你想要的。只要你告诉JDBCJobStore前缀是什么（在Quartz配置文件里）。使用不同的前缀可能用来在同一个数据库中创建多套数据表，供多个调度器实例使用。

        一旦你创建了数据表，在配置和触发JDBCJobStore之前你需要作多个重要决定。你需要决定你的应用需要什么类型的事务。如果你不需要把调度命令（例如添加和移除触发器）和其他事务捆绑在一起，那么你就让Quartz使用JobStoreTx作为JobStore管理事务（这个是最常用的选择）。

        如果你需要Quartz关联其他事务（例如在J2EE应用服务器中），然后你应该使用JobStoreCMT——这种情况下Quartz会让应用服务容器管理事务。

       最后一件难题是从JDBCJobStore中设置DataSource，用来获得数据库的连接。数据源在Quartz配置中定义，从几种不同方式中选择其中一种。一种方式是Quartz自己创建和管理数据源——通过提供所有的数据库连接信息。另一种方式是Quartz使用由Quartz运行所在的应用服务器中的数据源——将数据源的JNDI名字提供给JDBCJobStore。想了解更多参数的详细信息，请查阅“docs/config”文件夹的示例配置文件。

       假定你正在使用StdSchedulerFactory，想要使用JDBCJobStore时，只需要在Quartz配置文件中将JobStore class参数的值指定为org.quartz.impl.jdbcjobstore.JobStoreTX或org.quartz.impl.jdbcjobstore.JobStoreCMT的类全名即可——你可以根据上面几段文字中的解释决定你的选择。

Quartz配置文件中使用JobStoreTx

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

接下来，你需要选择DriverDelegate给JobStore使用。DriverDelegate负责完成任何JDBC的工作，它需要和指定的数据库类型对应。StdJDBCDelegate是使用“vanilla”JDBC代码和SQL语句完成工作的一种delegate。如果没有专门与你的数据库对应的delegate，尝试使用这个delegate——我们只是为数据库开发对应的delegates，并且已经发现使用StdJDBCDelegate的问题（好像是问题最多的）。其他的delegates可以在org.quartz.impl.jdbcjobstore包或子包中找到。其他的delegates包括DB2v6Delegate(DB2 6及更早版本), HSQLDBDelegate (HSQLDB数据库), MSSQLDelegate(微软SQLServer数据库),PostgreSQLDelegate (PostgreSQL数据库), WeblogicDelegate (使用Weblogic 的JDBC的数据库), OracleDelegate(Oracle数据库)和其他。

       一旦你选择了delegates，设置delegate的类全名给JDBCJobStore使用。

       使用DriverDelegate配置JDBCJobStore

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

接下来，你需要通知JobStore你使用的表前缀（前面讨论过）配置JDBCJobStore的表前缀

org.quartz.jobStore.tablePrefix = QRTZ_

最后，你需要设置JobStore使用哪个数据源。数据源的名字也必须在Quartz配置中定义。既然这样，我们指定Quartz的数据源的名字为“myDS”（即在配置文件另外的参数中定义）。

   配置JDBCJobStore的数据源名字：

org.quartz.jobStore.dataSource = myDS

如果调度器繁忙（例如几乎总是执行跟线程池一样多的作业任务），你可能需要设置数据源的连接数，大约比线程池数多2个。

org.quartz.jobStore.useProperties配置参数可以设置为“true”（默认为false），为了通知JDBCJobStore所有在JobDataMaps的值都会为String类型，因此可以作为键值对存储，而不是在BLOB列中存储序列化的对象。这从长远看来更安全，例如你可以避免将非String类对象序列化到BLOB中导致的类版本问题。

TerracottaJobStore

TerracottaJobStorer提供了一种不需要使用数据的可伸缩，健壮的方案。这意味着数据库在Quartz方面可以保持空载，而是将所有的资源保存在应用的其他部分中。

        TerracottaJobStore可以在集群或非集群环境中运行，在任何一种环境下，应用服务器重启期间都提供一个永久存储job数据的介质，因为这些数据存储在Terracotta服务器中。这个比通过JDBCJobStore使用数据库的方式高效（大约高一个数量级），但比RAMJobStore慢。

      假定你正在使用StdSchedulerFactory，想要使用TerracottaJobStore时，只需要在Quartz配置文件中将类名JobStore class参数的值指定为org.quartz.jobStore.class= org.terracotta.quartz.TerracottaJobStore，并且额外加一行配置指定Terracotta服务器地址。

  使用Terracotta配置Quartz

org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore
org.quartz.jobStore.tcConfigUrl = localhost:9510

更多关于JobStore和Terracotta的信息可以在这里找到：http://www.terracotta.org/quartz