Quartz 2.2 multi scheduler and @DisallowConcurrentExecution

Question

Please consider this example.

The sample web application calls scheduler.start() at startup. The scheduler is configured to store its tasks in the database.

The application is copied to six web servers.

So, if we run six web servers, we will have six schedulers with the same name in one database. As stated at https://quartz-scheduler.org/documentation/quartz-2.1.x/cookbook/MultipleSchedulers :

Never run (scheduler.start ()) a non-clustered instance against the same set of database tables that any other instance with the same scheduler name (start () ed) runs on. You can get serious data corruption and will certainly experience erratic behavior.

So it will not succeed.

My question is, if I’m sure that all my work assignments will @DisallowConcurrentExecution exceed the work, or it still fails ?!

---

If @DisallowConcurrentExecution doesn’t help, I have to do it manually to configure one server as some, like the Wizard

 public class StartUp implements ServletContextListener { public void contextInitialized(ServletContextEvent event) { if(THIS_IS_MASTER_TOMCAT){ scheduler.start() } } 

Are there any better ways ?!

Answer 1

Mostly Rene M. is correct. Here are the documents in question regarding quartz:

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

Now some background and conceptual example from our own use in my company. We use the quartz clustering mode in the Wildfly cluster. This is every cluster of wildlife node launches quartz. Since quartz works in the cluster mode itself and points to the same database schema, we guarantee that one task will be performed for each cluster. Again, see the documentation. Key issues are:

• One quartz cluster should work against one quartz database
  schemes. You obviously need to create relational database tables in the documentation. No, biggie.
• You must install the quartz.property files and a copy of which must exist for each node in the cluster. The same quartz.property file
• Finally, you must use a NonJTA data source, otherwise the quartz cluster will not work. This often means in the quartz world Wildfly will require a DataSource.

Example quartz.property:

  #============================================================================ # 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 fragment in 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 data element according to your requirements. @DisallowConcurrentExecution - It’s a good idea to prevent multiple jobs in the same node form that executes a specific method, but clustering quartz prevents the same work from being performed on multiple virtual machines; not this annotation.