Does Quartz's @DisallowConcurrentExecution work with multiple nodes?

[joaoportela]

@DisallowConcurrentExecution documentation doesn't clarify whether or not this works across a cluster.

I found some comments online that indicate that it only works on per-node basis.

• https://stackoverflow.com/a/35309239/86845
• Quartz scheduler does not support ConcurrentExecution.SKIP correctly quarkusio/quarkus#15800 (comment)

But looking at other sources, it seems that it is expected that it works across cluster nodes.

• @DisallowConcurrentExecution jobs with multiple triggers running concurrently #674
• @DisallowConcurrentExecution jobs are running at same time on different nodes when cluster de-synced #176
• https://stackoverflow.com/a/36152304/86845

I'm inclined to believe that it should work in cluster mode, but I would appreciate a final answer on this:

If I have multiple triggers for the same job (same job key), will the @DisallowConcurrentExecution annotation ensure that only one instance is running at a time in the entire cluster?

[GaoForGot]

Encountered relevant problem, here is my scenario,
I set up one job(one jobdetail) with @DissallowConcurrentExecution annotated running on a cluster with two nodes . The job is triggered by cronTrigger, the cron expression is (30/30 * * * * ? *) . The cluster uses jdbcjobstore. acquireTriggersWithinLock is set with true.
The result I expected is that the job triggered --> running --> finished by two nodes without concurrent overlap, however, they overlap like this occasionally:
node_1 start: 2022-01-25 14:09:25 end: 2022-01-25 14:19:25
node_2 start 2022-01-25 14:10:00 end: 2022-01-25 14:10:18
node_1's firing was actually a misfire handling(fire once now policy by default), it seems like node_2 didn't check the status of the trigger, acquired and executed it.
The concurrent running of this job has caused lots of unexpected problem, It's been troubling me for a month(searched everywhere, read the code, test by myself, still no clue, I'm not that good T-T). since joaoportela's question is strongly correlated with mine, so I post it here, hopefully I could get some help. Please let me know if I miss any info that can help solving the problem.

[jhouserizer]

Yes, it works with multiple nodes - it does so my marking all triggers of the job as "blocked" until execution finishes. It should be impossible for this not to happen if locking is enabled, see this block of code

quartz/quartz-core/src/main/java/org/quartz/impl/jdbcjobstore/JobStoreSupport.java

Line 3074 in b93d749

if (job.isConcurrentExectionDisallowed()) {

).

If concurrent executions are observed then that would be a bug that needs a replication test case and issue filed.

[ckuehne]

@jhouserizer
I can see that the triggerFired() method you link is executed in TXLock (e.g. executeInNonManagedTXLock()) but storeTrigger() when called (transitively) from recoverMisfiredJobs() ist not executed in a TXLock.

Just a guess:
Could there be a race condition: triggerFired() does updateTriggerStatesForJobFromOtherState for triggers of a DissallowConcurrentExecution job while recoverMisfiredJobs() -> storeTrigger() adds a new trigger for this job, and both are executed concurrently on different machines?