JobStore's are responsible for keeping track of all the "work data" that you give to the scheduler: jobs, triggers, calendars, etc. Selecting the appropriate IJobStore implementation for your Quartz scheduler instance is an important step. Luckily, the choice should be a very easy one once you understand the differences between them. You declare which JobStore your scheduler should use (and it's configuration settings) in the properties file (or object) that you provide to the SchedulerFactory that you use to produce your scheduler instance.
Never use a JobStore instance directly in your code. For some reason many people attempt to do this. The JobStore is for behind-the-scenes use of Quartz itself. You have to tell Quartz (through configuration) which JobStore to use, but then you should only work with the Scheduler interface in your code.
JobStore负责保持对所有scheduler “工作数据”追踪，这些工作数据包括：job（任务）,trigger（触发器）,calendar(日历)等。为你的Quartz scheduler选择合适的JobStore是非常重要的一步，幸运的是，如果你理解了不同的JobStore之间的差别，那么选择就变得非常简单。在提供产生scheduler 实例的SchedulerFactory的属性文件中声明scheduler所使用的JobStore（以及它的配置）。
注：不要在代码中直接使用JobStore实例，出于某些原因，很多人试图这么做。JobStore是由Quartz自身在幕后使用。你必须告诉（通过配置）Quartz使用哪个JobStore，而你只是在你的代码中使用Scheduler接口完成工作。
RAMJobStore
RAMJobStore is the simplest JobStore to use, it is also the most performant (in terms of CPU time). RAMJobStore gets its name in the obvious way: it keeps all of its data in RAM. This is why it's lightning-fast, and also why it's so simple to configure. The drawback is that when your application ends (or crashes) all of the scheduling information is lost - this means RAMJobStore cannot honor the setting of "non-volatility" on jobs and triggers. For some applications this is acceptable - or even the desired behavior, but for other applications, this may be disasterous.
RAMJobStore是最简单的JobStore，也是性能最好的（根据CPU时间）。从名字就可以直观地看出，RAMJobStore将所有的数据都保存在RAM中。这就是为什么它闪电般的快速和如此容易地配置。缺点就是当应用结束时所有的日程信息都会丢失，这意味着RAMJobStore不能满足Jobs和Triggers的持久性（“non-volatility”）。对于有些应用来说，这是可以接受的，甚至是期望的行为。但是对于其他应用来说，这将是灾难。
为了使用RAMJobStore（假设你使用DirectSchedulerFactory），指使简单地将类名Quartz.Simpl.RAMJobStore作为你的quartz的配置值。
Configuring Quartz to use RAMJobStore
quartz.jobStore.type = Quartz.Simpl.RAMJobStore, Quartz
To use RAMJobStore (and assuming you're using StdSchedulerFactory) you don't need to do anything special. Default configuration of Quartz.NET uses RAMJobStore as job store implementation.
这里没有其他需要的担心的配置。 Qiartz.net缺省使用的就是RAMJobStore.
ADO.NET Job Store (AdoJobStore)
AdoJobStore is also aptly named - it keeps all of its data in a database via ADO.NET. Because of this it is a bit more complicated to configure than RAMJobStore, and it also is not as fast. However, the performance draw-back is not terribly bad, especially if you build the database tables with indexes on the primary keys.
AdoJobStore的命名也非常得体，它将所有的数据通过ADO.NET保存到数据库可中。它的配置要比RAMJobStore稍微复杂，同时速度也没有那么快。但是性能的缺陷不是非常差，尤其是如果你在数据库表的主键上建立索引。
To use AdoJobStore, you must first create a set of database tables for Quartz.NET to use. You can find table-creation SQL scripts in the "database/dbtables" directory of the Quartz.NET distribution. If there is not already a script for your database type, just look at one of the existing ones, and modify it in any way necessary for your DB. One thing to note is that in these scripts, all the the tables start with the prefix "QRTZ_" such as the tables "QRTZ_TRIGGERS", and "QRTZ_JOB_DETAIL"). This prefix can actually be anything you'd like, as long as you inform AdoJobStore what the prefix is (in your Quartz.NET properties). Using different prefixes may be useful for creating multiple sets of tables, for multiple scheduler instances, within the same database.
AdoJobStore几乎可以在任何数据库上工作，它广泛地使用Oracle, MySQL, MS SQLServer2000, HSQLDB, PostreSQL 以及 DB2。要使用AdoJobStore，首先必须创建一套Quartz使用的数据库表，可以在Quartz 的database ables找到创建库表的SQL脚本。如果没有找到你的数据库类型的脚本，那么找到一个已有的，修改成为你数据库所需要的。需要注意的一件事情就是所有Quartz库表名都以QRTZ_作为前缀（例如：表"QRTZ_TRIGGERS",及"QRTZ_JOB_DETAIL"）。实际上，可以你可以将前缀设置为任何你想要的前缀，只要你告诉AdoJobStore那个前缀是什么即可（在你的Quartz属性文件中配置）。对于一个数据库中使用多个scheduler实例，那么配置不同的前缀可以创建多套库表，十分有用。
Currently the only option for the internal implementation of job store is JobStoreTX which creates transactions by itself. This is different from Java version of Quartz where there is also option to choose JobStoreCMT which uses J2EE container managed transactions.
The last piece of the puzzle is setting up a data source from which AdoJobStore can get connections to your database. Data sources are defined in your Quartz.NET properties. Data source information contains the connection string and ADO.NET delegate information.
Configuring Quartz to use JobStoreTx
1 quartz.jobStore.type = Quartz.Impl.AdoJobStore.JobStoreTX, Quartz
Next, you need to select a IDriverDelegate implementation for the JobStore to use. The DriverDelegate is responsible for doing any ADO.NET work that may be needed for your specific database. StdAdoDelegate is a delegate that uses "vanilla" ADO.NET code (and SQL statements) to do its work. If there isn't another delegate made specifically for your database, try using this delegate - special delegates usually have better performance or workarounds for database specific issues. Other delegates can be found in the "Quartz.Impl.AdoJobStore" namespace, or in its sub-namespaces.
NOTE: Quartz.NET will issue warning if you are using the default StdAdoDelegate as it has poor performance when you have a lot of triggers to select from. Specific delegates have special SQL to limit result set length (SQLServerDelegate uses TOP n, PostgreSQLDelegate LIMIT n, OracleDelegate ROWCOUNT() <= n etc.).
Once you've selected your delegate, set its class name as the delegate for AdoJobStore to use.
Configuring AdoJobStore to use a DriverDelegate
quartz.jobStore.driverDelegateType = Quartz.Impl.AdoJobStore.StdAdoDelegate, Quartz
Next, you need to inform the JobStore what table prefix (discussed above) you are using.
Configuring AdoJobStore with the Table Prefix
quartz.jobStore.tablePrefix = QRTZ_
And finally, you need to set which data source should be used by the JobStore. The named data source must also be defined in your Quartz properties. In this case, we're specifying that Quartz should use the data source name "myDS" (that is defined elsewhere in the configuration properties).
Configuring AdoJobStore with the name of the data source to use
quartz.jobStore.dataSource = myDS
One last thing that is needed for the configuration is to set data source connection string information and database provider. Connection string is the standard ADO.NET connection which is driver specific. Database provider is an abstraction of database drivers to create loose coupling between database drivers and Quartz.
Setting Data Source's Connection String And Database Provider
quartz.dataSource.myDS.connectionString = Server=localhost;Database=quartz;Uid=quartznet;Pwd=quartznet
quartz.dataSource.myDS.provider = MySql-50
Currently following database providers are supported:
- SqlServer-20 - SQL Server driver for .NET Framework 2.0
- OracleODP-20 - Oracle's Oracle Driver
- OracleODPManaged-1123-40 Oracle's managed driver for Oracle 11
- OracleODPManaged-1211-40 Oracle's managed driver for Oracle 12
- MySql-50 - MySQL Connector/.NET v. 5.0 (.NET 2.0)
- MySql-51 - MySQL Connector/:NET v. 5.1 (.NET 2.0)
- MySql-65 - MySQL Connector/:NET v. 6.5 (.NET 2.0)
- SQLite-10 - SQLite ADO.NET 2.0 Provider v. 1.0.56 (.NET 2.0)
- Firebird-201 - Firebird ADO.NET 2.0 Provider v. 2.0.1 (.NET 2.0)
- Firebird-210 - Firebird ADO.NET 2.0 Provider v. 2.1.0 (.NET 2.0)
- Npgsql-20 - PostgreSQL Npgsql
You can and should use latest version of driver if newer is available, just create an assembly binding redirect
If your Scheduler is very busy (i.e. nearly always executing the same number of jobs as the size of the thread pool, then you should probably set the number of connections in the data source to be the about the size of the thread pool + 1.This is commonly configured int the ADO.NET connection string - see your driver implementation for details.
The "quartz.jobStore.useProperties" config parameter can be set to "true" (defaults to false) in order to instruct AdoJobStore that all values in JobDataMaps will be strings, and therefore can be stored as name-value pairs, rather than storing more complex objects in their serialized form in the BLOB column. This is much safer in the long term, as you avoid the class versioning issues that there are with serializing your non-String classes into a BLOB.
如果Scheduler非常忙（比如，执行的任务数量差不多和线程池的数量相同，那么你需要正确地配置DataSource的连接数量为线程池数量。为了指示AdoJobStore所有的JobDataMaps中的值都是字符串，并且能以“名字-值”对的方式存储而不是以复杂对象的序列化形式存储在BLOB字段中，应设置 quartz.jobStore.useProperties配置参数的值为"true"(这是缺省的方式)。这样做，从长远来看非常安全，这样避免了对存储在BLOB中的非字符串的序列化对象的类型转换问题。
Configuring AdoJobStore to use strings as JobDataMap values (recommended)
quartz.jobStore.useProperties = true