Quartz Clustering - triggers duplicated when the server starts

Question

We are facing an issue while using Quartz 2.1.6 with Spring 3.1 in a clustered setup (with the JDBC data store). Current context:

• Jobs and CRON triggers are defined in the spring configuration file (see below)
• overwriteExistingJobs property is set to true in SchedulerFactoryBean, so we don't get new job definitions added to the DB with each deployment.
• However, after each deployment in the cluster, it seems that each node re-creates the trigger data. For example, if we have 2 triggers pointing to 1 job and 4 nodes, after the cluster deployment the DB has 1 job definition and 4x2 triggers. Each re-deployment adds 4x2 triggers.

Is this behavior normal? If yes: how can we tell Quartz not to re-create trigger data with each deployment? (or overwrite that data, as with Jobs)

<bean name="myJob" class="org.springframework.scheduling.quartz.JobDetailFactoryBean">
    <property name="jobClass" value="com.etc.MyJob" />
</bean>
<bean class="org.springframework.scheduling.quartz.SchedulerFactoryBean"
    p:waitForJobsToCompleteOnShutdown="false" lazy-init="false">

    <property name="dataSource" ref="myDataSource" />
    <property name="transactionManager" ref="transactionManager" />
    <property name="overwriteExistingJobs" value="true" />
    <property name="autoStartup" value="true" />
    <property name="jobFactory">
                <bean class="org.springframework.scheduling.quartz.SpringBeanJobFactory"/>
            </property>
    <property name="triggers">
        <list>
            <bean class="org.springframework.scheduling.quartz.CronTriggerFactoryBean" p:cronExpression="0 0 0 * * ?"                   p:misfireInstruction="2">
                <property name="jobDetail" ref="myJob" />
            </bean>
            <bean class="org.springframework.scheduling.quartz.CronTriggerFactoryBean "
                p:cronExpression="0 0 20 * * ?"
                p:misfireInstruction="2">
                <property name="jobDetail" ref="myJob" />
            </bean>
        </list>
    </property>
    <property name="quartzProperties">
        <props>
            <prop key="org.quartz.scheduler.instanceName">fsbu_scheduler</prop>
            <prop key="org.quartz.scheduler.instanceId">AUTO</prop>

            <prop key="org.quartz.jobStore.misfireThreshold">60000</prop>
            <prop key="org.quartz.jobStore.class">org.quartz.impl.jdbcjobstore.JobStoreTX</prop>
            <prop key="org.quartz.jobStore.driverDelegateClass">org.quartz.impl.jdbcjobstore.oracle.weblogic.WebLogicOracleDelegate
            </prop>
            <prop key="org.quartz.jobStore.selectWithLockSQL">SELECT * FROM {0}LOCKS WHERE SCHED_NAME = {1} AND LOCK_NAME = ? FOR UPDATE
            </prop>
            <prop key="org.quartz.jobStore.tablePrefix">fsqrz_</prop>
            <prop key="org.quartz.scheduler.skipUpdateCheck">true</prop>
            <prop key="org.quartz.jobStore.isClustered">true</prop>
            <prop key="org.quartz.threadPool.class">org.quartz.simpl.SimpleThreadPool</prop>
            <prop key="org.quartz.threadPool.threadCount">3</prop>
            <prop key="org.quartz.plugin.triggHistory.class">org.quartz.plugins.history.LoggingTriggerHistoryPlugin
            </prop>
            <prop key="org.quartz.plugin.triggHistory.triggerFiredMessage">Trigger {1}.{0} fired job {6}.{5} at {4, date,
                yyyy-MM-dd HH:mm:ss}
            </prop>
            <prop key="org.quartz.plugin.triggHistory.triggerCompleteMessage">Trigger {1}.{0} completed firing job {6}.{5} at {4,
                date, yyyy-MM-dd HH:mm:ss} with resulting trigger instruction code
                {9}
            </prop>
        </props>
    </property>
</bean>

Answer 1

The bean definition for each Trigger did not have the "name" attribute. Therefore, Spring's CronTriggerFactory was dynamically generating a new trigger name with each deployment, being the reason why this caused an additive effect (triggers with different names are not overwritten).

Adding name="..." with an unique value to each trigger definition solved the issue.