Quartz调度时好时坏解决方案

    最近同事向我报怨说：选用的作业调度框架Quartz不稳定，具体规律表现为分奇偶次调度，比如第一次可以调度，第二次就不能调度了，依次类推。
    我建议说：最不济办法采用先删除后添加调度信息方式应该可以。
    他说：试过了，故障依旧。
    。。。。。。有这种事？
   
    小平同志说：实践是检验真理的唯一标准。
    按我同事要求的方法我如法炮制一番，现象和结论竟然与他说的一样一样的，这令我大跌眼镜。
    Quartz是比较成熟的开源作业调度框架，除了这个JAVA版本，还有一个.NET版本呢，怎么会有这么大BUG呢？不可能！一定是我们哪个地方没处理好。
    凡事讲究证据才会令人信服，不然会沦落为被人掷鞋的小布什^_^
    通过一番仔细观察取证，我发现：
    1、当qrtz_fire_triggers(以qrtz_为前缀是quartz系统表，下同)表中有该任务正在执行，此时就是采用先删后加方式进行调度，她也会删除qrtz_fire_triggers中那个任务，同时，也会把
qrtz_triggers表中该任务状态置为BLOCKED（堵塞），这样该任务当然不会被触发。
    2、当qrtz_fire_triggers表中没有该任务正在执行，此时就是采用先删后加方式进行调度，该任务就会立即触发。
    3、当qrtz_triggers表中该任务状态是BLOCKED时，手动修改qrtz_triggers表中该任务状态为WAITINNG，该任务也会立即触发。
    原来一直以为调用其API中new JobDetail()方法就会自动往qrtz_job_details写一条数据，调用其API中new trigger()方法就会自动往qrtz_triggers表里写一条数据。事实并非如此，调用sched.scheduleJob(jobDetail, trigger)时才会自动往相应表中写数据。并在调用sched.start()方法后，才会执行上述三条操作。
    综上所述，我在sched.start()方法后再每次更新其qrtz_triggers表中该任务状态为WATING，就解决了该问题。