JobStore是负责跟踪调度器中所有的工作数据：作业任务、触发器、日历等。为你的Quartz调度器实例选择一个适当的JobStore是非常重要的一步。幸运的是，一旦你理解了这些JobStore之间的区别，选择它们是非常容易的事。你可以在配置文件（或是类对象）中定义调度器使用哪种JobStore，这个JobStore将会提供给SchedulerFactory，用来创建你的调度器实例。
不要在你的代码中直接使用JobStore实例，因为一些原因许多开发者尝试这样做。JobStore是给Quartz在幕后使用的。你只需要通过配置信息告知Quartz该用哪个JobStore，然后在你的代码里只需要使用调度器接口即可。
RAMJobStore
RAMJobStore是最容易使用的JobStore，它也是最高效的（从CPU时间计算）。从RAMJobStore的名字可以明显地发现：它将所有数据存储在RAM中。这就是为什么它速度快并且配置简单的原因。缺点是当你的应用终止（或是崩溃）时，所有的调度信息都会丢失——这意味着RAMJobStore会导致作业任务和触发器的non-volatility设置不起作用。对某些应用来说，这种缺点可以接受，甚至需要这样的特性，但对另外一些应用来说，这种缺点可能会成为一个灾难。
假定你正在使用StdSchedulerFactory，想要使用RAMJobStore时，只需要在Quartz配置文件中将JobStore class参数的值指定为org.quartz.simpl.RAMJobStore的类全名即可：
Quartz配置文件中使用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