Search code examples
javaquartz

Are Quartz jobs running in the same JVM in their own threads?

Quartz scheduler is used to schedule timed java jobs at my workplace. The scheduler itself is deployed as an application to a Weblogic servers (a cluster of machines). This scheduler can schedule jobs which implement the Job interface and override the execute() method. These jobs are deployed to the Weblogic servers as libraries which are then used by the scheduler. (One library includes multiple jobs.)

I have not managed to find informative sources on how these jobs are run or how they share resources. I looked at the Quartz documentation but could not find what I was looking for.

I have multiple questions, though I believe a single answer may cover all of them.

  1. Do all the jobs created through the scheduler share a single JVM? If they don't, then based on what is a job allocated to a given JVM?
  2. I assume that a separate thread is allocated to each job - is that correct?
  3. If all scheduled jobs run in the same JVM and each has its own thread, then concurrent execution of the same job with different parameters will create a need for making the job thread safe or a need to disable concurrent execution of the job, will not it?

Thank you.

Solution

  • You may want to read Quartz scheduler tutorial to find out how Quartz works. To answer your questions:

    1. This depends on whether you run a Quartz scheduler cluster (i.e. multiple Quartz scheduler instances sharing the same job store) or a standalone Quartz scheduler instance. In clustered deployments, individual Quartz scheduler instances compete to execute jobs by creating DB row locks. The scheduler instance that first manages to create the row lock, is the scheduler instance that executes a particular job. In a standalone Quartz scheduler deployment, the completion does not exist and it is always the single Quartz scheduler instance that ends up executing all jobs.

    2. Quartz uses a thread pool and when it needs to execute a job, it simply allocates a free thread from the pool and uses it to execute the job. After the job finishes executing, Quartz returns the thread back to the pool.

    3. Instances of Quartz job implementation classes are not shared. That means, when Quartz is about to execute a job, it instantiates the configured org.quartz.Job class and invokes its execute method passing it the job execution context as a parameter. Once the job execution completes, the org.quartz.Job instance is discarded and eventually garbage-collected, i.e. it is not reused by Quartz. If your org.quartz.Job class declares / accesses some static fields, singletons etc., then you may need to synchronize access to these shared resources where necessary.