This guide covers:
During Quartz operation, it has to do some housekeeping: track trigger execution history, trigger and job state, misfires and so on. By default Quartz keeps this information in memory. In some cases it is all you need but has obvious drawbacks:
To address this issue, Quartz supports durable job stores. They store all the scheduler state, not just information about jobs.
Quartz comes with a JDBC-backed job data store out of the box. There is also a MongoDB-backed one.
For more information, see Quartz documentation on JDBC-backed durable Quartz stores.
Clojure is a compiled language: code is compiled when it is loaded (usually via
clojure.core/require). To dynamically
load classes Clojure code compiles to, Clojure uses a special class loader. Since Quartz also uses its own class loader,
due to the JVM security model it cannot see job classes Clojure compiler generates.
A solution to this issue is described in the following section.
A solution to the different class laoders issue is to subclass the job store class and (if it allows this) make it use
and then configure Quartz to use it via the
For more information about mixed Clojure/Java projects, see Clojure/Java projects with Leiningen 2+.
Future versions of Quartzite may ship with custom job classes like this out of the box.
Quartz provides support for durable stores for its state. Using a durable store is a good idea for availability reasons. Due to specifics of how Clojure compiler and Quartz scheduler work, using durable stores with Quartzite requires a little bit of glue code. Quartzite authors continue looking for a good generic solution.
This guide covers Quartzite