The job of JobStroe is to hold all the "job data" you give the scheduler: Job, Trigger, Calendar, etc. Choosing the right JobStore for your Quartz Scheduler instance is an important step. Fortunately, if you understand the differences between the various JobStores, the choice will be very easy. Declaring which JobStore to use requires the use of a properties file, which can be provided to the SchedulerFactory for creating scheduler instances.
Do not use the JobStore object directly in your code. There are many developers who do this for some reason. The JobStore is supposed to work behind the scenes in Quartz. You need to tell Quartz which JobStore to use (via the configuration file), and then use only the Scheduler object in your code.
RAMJobStore
RAMJobStore is the easiest JobStore to use, and it also has the highest performance (measured in CPU time). From the name of RAMJobStore: it will keep all data in RAM. That's why it's the lightest and easiest to configure. The downside is that when your application ends or crashes, all scheduler data will be lost - which means, RAMJobStore will not honor the "non-volatility" settings on Job and Trigger. For some applications this is acceptable (or even expected), but for others it can be a disaster. To use RAMJobStore (assuming you are using StdSchedulerFactory), simply set the JobStore configuration item to org.quartz.simpl.RAMJobStore in the Quartz configuration file:
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore
| org . quartz . jobStore . class = org . quartz . simpl . RAMJobStore |
Next, you don't need to think about any other configuration.
JDBCJobStore
JDBCJobStore saves all data to the database through JDBC. Therefore, the configuration is slightly more complicated than RAMJobStore, and it is also slower. However, this performance lag is not particularly large, especially if you create an index on the primary key when you create the database table. If the LAN (between scheduler and database) of a group of machines is in good condition, the whole process of fetching and updating the trigger trigger will generally not take more than 10 milliseconds. JDBCJobStore can be used with almost any database, including Oracle, PostgreSQL, MySQL, MS SQLServer, HSQLDB, and DB2. To use JDBCJobStore, you must first create a set of database tables for Quartz. The script to create the table is in the "docs/dbTables" directory of the Quartz distribution. If the script is not suitable for the type of database you are using, you can modify the script according to your needs. One thing to note, in these scripts, all database tables are prefixed with "QRTZ_" (eg tables "QRTZ_TRIGGERS" and "QRTZ_JOB_DETAIL"). In fact, you can use any prefix you like, just tell JDBCJobStroe which prefix to use in the Quartz properties file. Using different prefixes can be useful if you need to store data in the same database using different database tables for multiple scheduler instances.
Once the database tables are created, there is one more decision to make before using the JDBCJobStore. You need to decide which type of transaction mechanism your application will use. If you don't need to bind your scheduler commands (such as adding and removing triggers) to other transactions, then JosStore can manage transactions via JobStoreTX (this is also the most common choice).
如果你需要 Quzrtz 协同其它事务一起工作（例如，在 Java EE 应用服务器中），那么你需要使用 JobStoreCMT——这样，Quartz 将会让应用程序服务器来管理事务。
最后一点是如何创建 DataSource，好让 JDBCJobStore 从你的数据库中获取连接。.DataSource 在 Quartz 属性文件中，有几种不同的配置方法。一种方式是让 Quartz 自己创建并管理 DataSource —— 这需要提供数据库的所有连接信息。另一种方式是让 Quartz 使用应用程序服务器提供的 DataSource —— 提供给 JobStore DataSource 的 JNDI 名称。详细的配置可以参考“docs/config” 目录下的配置文件。
要使用 JDBCJobStore（假设你正在使用 StdSchedulerFactory），首先需要设置 Quartz 配置项，让 JobStore 类的属性是 org.quartz.impl.jdbcjobstore.JobStoreTX 或 org.quartz.impl.jdbcjobstore.JobStoreCMT —— 具体选择哪个值取决于上面的描述。
配置 Quartz 使用 org.quartz.impl.jdbcjobstore.JobStoreTX：
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
| org . quartz . jobStore . class = org . quartz . impl . jdbcjobstore . JobStoreTX |
接下来，你需要设置 JogStore 使用的 DriverDelegate。DriverDelegate 的作用是为特定的数据库执行 JDBC 的工作。StdJDBCDelegate 使用标准 JDBC 代码（和 SQL 语句）来做这个工作，如果没有其它合适的 delegate 适用于你的数据库，那么你可以试试使用 StdJDBCDelegate。其它的 delegate 可以在 “org.quartz.impl.jdbcjobstore” 包，或者在它的子包中找到。其它 delegate 包括 DB2v6Delegate （DB2 版本 6 或早期版本）、 HSQLDBDelegate （HSQLDB）、MSSQLDelegate（Microsoft SQLServer）、PostgreSQLDelegate （PostgreSQL）、WeblogicDelegate（使用 Weblogic 创建的 JDBC 驱动）、 OracleDelegate （Oracle）、等等。
一旦选择好使用哪个 delegate，那么就可以在属性文件中设置它的类名。
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate
| org . quartz . jobStore . driverDelegateClass = org . quartz . impl . jdbcjobstore . StdJDBCDelegate |
接下来，需要配置 JobStore 使用的数据库表前缀（前面讨论过）：
org.quartz.jobStore.tablePrefix = QRTZ_
| org . quartz . jobStore . tablePrefix = QRTZ_ |
最后，你需要设置使用哪个 DataSource。DataSource 名必须定义到 Quartz 属性文件中。在下面的例子中我们使用“myDS”作为 DataSource 名：
org.quartz.jobStore.dataSource = myDS
| org . quartz . jobStore . dataSource = myDS |
如果你的 Scheduler 很繁忙（例如，执行的任务数和线程池的大小总是差不多），那么你可能要设置 DataSource 中的连接数是线程池中的大小 + 2。
可以设置 org.quartz.jobStore.useProperties 属性值为 true（默认是 false），目的是为了让 JDBCJobStore 中的 JobDataMap 中的所有值都是 String 类型，这样方便存储键值对，而不是使用序列化的方式将复杂的对象存储到 BLOB 字段中。在长期看来，这将会更安全，因为你避免了类的版本的问题。
TerracottaJobStore
TerracottaJobStore 提供了一种不使用数据库，并且灵活的和健壮的手段。这意味着你的数据库可以不用加载任何 Quartz 的数据，这样可以为你的应用程序节省更多的数据库资源。
TerracottaJobStore 可以在集群或非集群的环境下使用，无论哪种环境都会在应用程序重启的时候为 Job 数据提供储存介质。这些数据是存储在 Terracotta 服务器中。它的性能会比通过 JDBCJobStore 使用数据库更高，但是会低于使用 RAMJobStore。
要使用 TerracottaJobStore （假设你使用 StdSchedulerFactory），只需要简单的在属性文件中设置 org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore，并另起一行设置 Terracotta 服务器的位置：
org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore
org.quartz.jobStore.tcConfigUrl = localhost:9510
|
org . quartz . jobStore . class = org . terracotta . quartz . TerracottaJobStore org . quartz . jobStore . tcConfigUrl = localhost : 9510 |