Using Memory to Store Scheduler Information

Out of the box, Quartz is configured to store job and trigger information in memory. This explains why, for the examples in the past several chapters, every time we restarted the Quartz application, the Scheduler state, including job and trigger information, was lost. Each time the Java Virtual Machine (JVM) is halted, its memory is released back to the operating system, and any information about jobs and triggers is lost with it.

The memory job storage facility for Quartz is provided by a class called org.quartz.simpl.RAMJobStore, which, as we said, implements the JobStore interface. The RAMJobStore is the out-of-the-box solution for Quartz. By this, we mean that unless you change the configuration, this is the JobStore that will be used for any Quartz application. Using this JobStore over the others brings several advantages.

First, the RAMJobStore is the easiest JobStore to configure: It's already configured for you. When you download and install Quartz, it's configured to use the RAMJobStore as the storage mechanism. You can see this in the default quartz.properties file, shown in Listing 6.1.

Listing 6.1. Default quartz.properties File When No Other Is Configured

# Default Properties file for use by StdSchedulerFactory
# to create a Quartz Scheduler Instance, if a different
# properties file is not explicitly specified.

org.quartz.scheduler.instanceName = DefaultQuartzScheduler
org.quartz.scheduler.rmi.export = false
org.quartz.scheduler.rmi.proxy = false
org.quartz.scheduler.wrapJobExecutionInUserTransaction = false
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 10
org.quartz.threadPool.threadPriority = 5
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true

org.quartz.jobStore.misfireThreshold = 60000

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

Listing 6.1 shows the default quartz.properties file that is included with the Quartz binary. When you don't include a quartz.properties file of your own in your application, this is the properties file that gets used. You can see from the last line in the default quartz.properties file that the RAMJobStore is the default value for the configuration property named org.quartz.jobstore.class. Even if the org.quartz.jobstore.class property is not set in quartz.properties, the RAMJobStore is the default JobStore that is used. This is hardwired into the Scheduler factory initialization routine.

Another advantage to using the RAMJobStore is its speed. Because all the Scheduler information is stored in the computer's memory, accessing this data is as fast as it gets. There are no out-of-process calls, no database connectionsjust plain old simple memory access. It doesn't get any better.

Job Volatility with RAMJobStore

You might remember from Chapter 4, "Scheduling Jobs," that jobs can be configured with a volatility property. When the volatility property is set to false, the job will be persisted between application shutdowns. This is not true when the RAMJobStore is being used; that behavior is explicitly reserved for persistent JobStores.

Configuring the RAMJobStore

Configuring your Quartz application to use the RAMJobStore is extremely easy. If you are using a custom quartz.properties file, not the one that comes with the Quartz JAR file, add this line to your properties file:

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

That's all you have to do to use the RAMJobStore. As we said, it doesn't get any easier.

Loading Jobs into the RAMJobStore

If the purpose of the RAMJobStore is to store Scheduler information, how does that information get loaded into memory in the first place? You can load job information in two ways. First, you can hardcode your jobs, triggers, calendars, and listeners into the code itself. As Chapters 3, "Hello, Quartz," and 4, "Scheduling Jobs," pointed out, however, this is always a dangerous thing to do because maintenance can become a nightmare. Any change, regardless of how trivial it is, requires a code change and recompile. Even if the change is a change to the firing times, code has to be modified and recompiled. Not a big deal, you say? That might be true for small, trivial applications, but this can become a real problem for larger numbers of jobs and triggers.

The second approach is to use the JobInitializationPlugin, which is discussed in detail in Chapter 8, "Using Quartz Plug-Ins." This Quartz plug-in uses an XML file to load jobs, triggers, calendars, and everything else that you need to load. The advantage to this approach is that a change requires a simple change to the XML fileno code changes, no recompilation, just a text editor. Read Chapter 8 for more information on Quartz plug-ins.

Disadvantage to RAMJobStore

"The RAMJobStore can't be all positive, right?" you ask. Well, that's true. We mentioned several of the advantages of using a RAMJobStore. Now let's talk about the one big negative: Because a computer's memory is volatile, when your Quartz application is stopped, it releases the memory back to the operating system. Of course, along with everything else stored in that released memory is the scheduling information.

If your application requires Scheduler information to be maintained between application restarts, you need to take a look at persistent JobStores.

Using Persistent JobStores