重新启动后,Quartz XML插件重新计划了触发的触发器 [英] Quartz XML plugin reschedules fired triggers after restart

查看:67
本文介绍了重新启动后,Quartz XML插件重新计划了触发的触发器的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用 XML计划插件( XMLSchedulingDataProcessorPlugin )以创建多个作业,并在.效果很好,但是我将简单触发器配置为只能运行一次就遇到了问题.

I am using XML Scheduling Plugin (XMLSchedulingDataProcessorPlugin) to create several jobs and triggers on startup in JDBC job store in quartz-scheduler. This works fine but I have a problem with simple triggers configured to run only once.

触发此类触发器时,由于没有下一次触发时间,因此将其从数据库中删除.到现在为止还挺好.不幸的是,当我重新启动应用程序时,插件找不到该触发器,因此再次将其重新插入.因为我使用 MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY ,所以此作业被再次触发,并再次从数据库中删除.重新启动应用程序会重复整个过程.

When such a trigger fires, it is removed from the database as there is no next fire time. So far so good. Unfortunately when I restart the application the plugin can't find that trigger so it is reinserted again. Because I use MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY this job is fired again and again removed from the database. Restarting the application repeats the whole process.

很显然,我只希望触发一次.即使没有下一次触发时间,也可以将触发的触发器保留在数据库中吗?还是可以用其他方式解决?摘录自我的 quartz_data.xml 文件:

Obviously I want my trigger to fire only once. Is it possible to keep fired triggers in the database even if they don't have next fire time? Or maybe this can be solved in a different way? Excerpt from my quartz_data.xml file:

<processing-directives>
    <overwrite-existing-data>false</overwrite-existing-data>
    <ignore-duplicates>true</ignore-duplicates>
</processing-directives>

<schedule>

    <trigger>
        <simple>
            <!-- ... -->
            <start-time>2012-05-10T07:00:00Z</start-time>
            <repeat-count>0</repeat-count>
            <repeat-interval>0</repeat-interval>
        </simple>
    </trigger>

请注意,所有到达最后一次执行的触发器都存在问题,因此已从数据库中删除.

Note that there is a problem with all triggers that reached the last execution and hence were deleted from db.

推荐答案

我最终扩展了 StdJDBCDelegate ,并将 deleteTrigger()覆盖为no-op:

I ended up extending StdJDBCDelegate and overriding deleteTrigger() to be no-op:

package com.example;

class DurableTriggersDriverDelegate extends StdJDBCDelegate {

    public DurableTriggersDriverDelegate(Logger logger, String tablePrefix, String schedName, String instanceId, ClassLoadHelper classLoadHelper) {
        super(logger, tablePrefix, schedName, instanceId, classLoadHelper);
    }

    public DurableTriggersDriverDelegate(Logger logger, String tablePrefix, String schedName, String instanceId, ClassLoadHelper classLoadHelper, Boolean useProperties) {
        super(logger, tablePrefix, schedName, instanceId, classLoadHelper, useProperties);
    }

    @Override
    public int deleteTrigger(Connection conn, TriggerKey triggerKey) throws SQLException {
        this.logger.debug("deleteTrigger(" + conn + ") skipped");
        return 1;
    }
}

可以通过 quartz.properties 轻松插入新的实现:

The new implementation can be easily plugged-in via quartz.properties:

org.quartz.jobStore.driverDelegateClass=com.example.DurableTriggersDriverDelegate

此解决方案有几个缺点:

This solution has several drawbacks:

  • 数据库不断增长,没有删除触发的触发器

  • the database keeps growing and growing, not deleting fired triggers

删除作业是不可能的,因为它首先尝试删除所有触发器(但是不执行此操作),并且在尝试删除作业详细信息本身时发生约束冲突

deleting job is not possible since it first tries to delete all triggers (but this is not performed) and constraint violation occurs when trying to delete the job details itself

但是它解决了我原来的问题.

However it solved my original problem.

这篇关于重新启动后,Quartz XML插件重新计划了触发的触发器的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆