What does each table for quartz scheduler signify?

Question

There are few tables that quartz scheduler uses for scheduling jobs and to identify which job is running currently. It uses the following tables :

 qrtz_fired_triggers
 qrtz_simple_triggers
 qrtz_simprop_triggers
 qrtz_cron_triggers
 qrtz_blob_triggers
 qrtz_triggers
 qrtz_job_details
 qrtz_calendars
 qrtz_paused_trigger_grps
 qrtz_locks
 qrtz_scheduler_state

So what is the purpose of each of these tables and what does it siginifies?

Thanks in advance.

Answer 1

I had the chance to work on quartz recently. I'm myself not 100% clear on this topic and I'm going to try my best to answer your question from my personal experience.

You must remember this basic flow- 1. Create a job. 2. Create a Trigger. 3. Scheduler(job, trigger) All the above tables are based on the above 3 steps.

1. qrtz_triggers is where general information of a trigger is saved.
2. qrtz_simple_triggers, qrtz_simprop_triggers, qrtz_crons_triggers, qrtz_blob_triggers have a foreign key relation to qrtz_triggers which save those specific details. Ex. Cron has cron expression which is unique to it.
3. qrtz_job_details is simply the task to be executed.
4. qrtz_fired_triggers is a log of all the triggers that were fired.
5. qrtz_paused trigger is to save the information about triggers which are not active.
6. Calendars are useful for excluding blocks of time from the the trigger’s firing schedule. For instance, you could create a trigger that fires a job every weekday at 9:30 am, but then add a Calendar that excludes all of the business’s holidays. (taken from website. I havent' worked on it)
7. I honestly haven't worked in qrtz_locks, qrtz_scheduler_sate tables.

Check out this image which I reverse engineered using MySQL workbench.

Answer 2

I can provide some inputs for qrtz_lock and qrtz_scheduler_sate tables:

1. qrtz_lock stores the value of the instance name executing the job, to avoid the sceanario of multiple nodes executing the same job

2. qrtz_scheduler_state is for capturing the node state so that if in any case one node gets down or failed to execute one of the job then the other instance running in clustering mode can pick the misfired job.