Job Store are used to keep track of all the "work
data" that you give to the scheduler: jobs, triggers, calendars, etc. The
important step for Quartz Scheduler step is selecting the appropriate JobStore. 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.
The JobStore is for behind-the-scenes use of Quartz itself. That's why never use JobStore instance directly in you code. Through configuration you have to tell to Quartz which JobStore to use, but then you should only work with the Scheduler interface in your code.
RAMJobStore is used to keep all of its data in RAM. That's why it is most performant (lightning fast in terms of CPU time) and simple to configure. The disadvantage is only that at the time of application crashes or ends all of the scheduling information is lost - this means RAMJobStore cannot honor the setting of "non-volatility" on jobs and triggers. In other words, this method's major deficiency is lack of data persistence because it kept all the data in RAM, all information will be lost upon an application or system crash.
Configuring Quartz to use RAMJobStore :
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore
To solve this problem, Quartz offers the JDBCJobStore. This job store keeps all data in a database through JDBC. The trade-off for data persistence is a lower level of performance, as well as a higher level of complexity.
As the name infers, it stores all data in a database via JDBC. That's why it is a little bit more complicated to configure and it is also as faster than RAMJobStore. But the performance deficiency is not terrible bad, especially when you make the database with indexes on the primary keys. The JDBCJobStore is compatible with all major databases, it mostly used with Oracle, MySQL, DB2, MS SQLServer2000.
For using JDBCJobStore your application required two steps. These are follows :
If your Scheduler is very busy that means it always executing the same number of jobs as the size of the thread pool, then in the DataSource you should set the number of connections about the size of the thread pool + 1.
If you are facing any programming issue, such as compilation errors or not able to find the code you are looking for.
Ask your questions, our development team will try to give answers to your questions.