Quartz 2.2 multi scheduler and @DisallowConcurrentExecution

Question

Please consider this example.

A sample web application calls scheduler.start() on its start up. The scheduler configured to store its jobs in DB.

The application is copied on six web-servers.

So if we start six web-servers we will have six scheduler with same name on a single DB. As mentioned in https://quartz-scheduler.org/documentation/quartz-2.1.x/cookbook/MultipleSchedulers:

Never start (scheduler.start()) a non-clustered instance against the same set of database tables that any other instance with the same scheduler name is running (start()ed) against. You may get serious data corruption, and will definitely experience erratic behavior.

So this will fail.

My question is that if I am sure that all of my jobs have @DisallowConcurrentExecution will above work or it will still fail ?!

---

If @DisallowConcurrentExecution does not help, I should do it manually configure one server as some how Master

public class StartUp implements ServletContextListener {

   public void contextInitialized(ServletContextEvent event) {
       if(THIS_IS_MASTER_TOMCAT){
         scheduler.start()
       }
}

Are there better ways?!

Answer 1

Basically Rene M. is correct. Here are the docs in question vis-a-vis Quartz:

http://www.quartz-scheduler.org/documentation/quartz-2.2.x/configuration/ConfigJDBCJobStoreClustering.html

Now some background and a conceptual example from our own use at my company. We use quartz clustering mode within a Wildfly Cluster. That is each wildfly cluster node runs quartz. Since quartz is running in cluster mode itself and is pointed at the same database schema we are guaranteed to run one job per cluster. Again, see the documentation. The key issues are this:

1. A single quartz cluster must run against a single quartz database
   schema. You obviously must create the relational database tables per the documentation. No biggie.
2. You must set the quartz.property files properly and a copy of which must exist for each node in the cluster. The same exact quartz.property file
3. Lastly you must use a NonJTA datasource otherwise the quartz cluster will fail. That often means in Wildfly world quartz will require its own datasource.

quartz.property example:

    #============================================================================
# Configure Main Scheduler Properties 
#============================================================================

org.quartz.scheduler.instanceName = BjondScheduler
org.quartz.scheduler.instanceId = AUTO

#============================================================================
# Configure ThreadPool 
#============================================================================

org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 5

#============================================================================
# Configure JobStore 
#============================================================================

org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreCMT
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
org.quartz.jobStore.useProperties = false
org.quartz.jobStore.tablePrefix=QRTZ_
org.quartz.jobStore.isClustered = true
org.quartz.jobStore.clusterCheckinInterval = 5000

org.quartz.scheduler.wrapJobExecutionInUserTransaction = true
org.quartz.scheduler.userTransactionURL = java:jboss/UserTransaction

org.quartz.jobStore.dataSource = PostgreSQLDS
org.quartz.jobStore.nonManagedTXDataSource = PostgreSQLDSNoJTA

org.quartz.dataSource.PostgreSQLDSNoJTA.jndiURL=java:jboss/datasources/PostgreSQLDSNoJTA
org.quartz.dataSource.PostgreSQLDS.jndiURL=java:jboss/datasources/PostgreSQLDS


#============================================================================
# Configure Logging
#============================================================================
#org.quartz.plugin.jobHistory.class=org.quartz.plugins.history.LoggingJobHistoryPlugin
#org.quartz.plugin.jobHistory.jobToBeFiredMessage=Bjond Job [{1}.{0}] to be fired by trigger [{4}.{3}] at: {2, date, HH:mm:ss MM/dd/yyyy} re-fire count: {7}
#org.quartz.plugin.jobHistory.jobSuccessMessage=Bjond Job [{1}.{0}] execution complete and reports: {8}
#org.quartz.plugin.jobHistory.jobFailedMessage=Bjond Job [{1}.{0}] execution failed with exception: {8}
#org.quartz.plugin.jobHistory.jobWasVetoedMessage=Bjond Job [{1}.{0}] was vetoed. It was to be fired by trigger [{4}.{3}] at: {2, date, dd-MM-yyyy HH:mm:ss.SSS}

Now our datasource snippet within standalone.xml:

            <datasource jta="false" jndi-name="java:jboss/datasources/PostgreSQLDSNoJTA" pool-name="PostgreSQLDSNoJTA" enabled="true" use-java-context="true" use-ccm="true">

You fill in the rest of this datasource element per your requirements. The @DisallowConcurrentExecution is a good idea to prevent multiple jobs on a single node form executing a particular method but it is the quartz clustering that prevents the same job running on multiple VM's; not this annotation.