Quartz scheduled executions

Quartz scheduled executions

这周被Quartz折腾了一番。
我们知道，Quartz采用JobDataMap实现向Job实例传送配置属性，正如Quartz官方文档说的那样：

How can I provide properties/configuration for a Job instance? The key is the JobDataMap, which is part of the JobDetail object.
The JobDataMap can be used to hold any number of (serializable) objects which you wish to have made available to the job instance when it executes.
JobDataMap map ＝ context.getJobDetail().getJobDataMap();

我们通过map向Job实例传送多个objects，其中有一个是个bean，一个是基本类型。对于scheduled triggers，我们要求bean对于所有的序列都不变，包括其属性，而基本类型可以在Job运行过程中改变，并影响下一个序列。实际情况是，对于下个序列，bean的属性被上次的修改了，而基本类型却维持第一次put到Map里面的值。正好和我们要求的相反。

受bean的影响，以为map里面包含的都是更新的对象，即每个序列里面的JobDetail是同一个对象，但是基本类型的结果否认了这一点。回头重新翻阅了下Quartz的文档：

Now, some additional notes about a job's state data (aka JobDataMap): A Job instance can be defined as "stateful" or "non-stateful". Non-stateful jobs only have their JobDataMap stored at the time they are added to the scheduler. This means that any changes made to the contents of the job data map during execution of the job will be lost, and will not seen by the job the next time it executes.

Job有两个子接口：StatefulJob and InterruptableJob，我们继承的是InterruptableJob，或许Quartz应该有个InterruptableStatefulJob。另外StatefulJob不支持并发执行，和我们的需求不匹配，我们有自己的同步控制，Job必须可以并发运行。

然后查看了Quartz的相关源码：

//  RAMJobStore.storeJob
public   void  storeJob(SchedulingContext ctxt, JobDetail newJob,
             boolean  replaceExisting)  throws  ObjectAlreadyExistsException {
        JobWrapper jw  =   new  JobWrapper((JobDetail)newJob.clone());  //  clone a new one
        .
        jobsByFQN.put(jw.key, jw);
        
}

也就是说，store里面放的是初始JobDetail的克隆，在序列运行完时，只有StatefulJob才会更新store里面的JobDetail：

//  RAMJobStore.triggeredJobComplete
public   void  triggeredJobComplete(SchedulingContext ctxt, Trigger trigger,
            JobDetail jobDetail,  int  triggerInstCode) {
    JobWrapper jw  =  (JobWrapper) jobsByFQN.get(jobKey);
    
     if  (jw  !=   null ) {
        JobDetail jd  =  jw.jobDetail;
         if  (jd.isStateful()) {
            JobDataMap newData  =  jobDetail.getJobDataMap();
             if  (newData  !=   null ) {
                newData  =  (JobDataMap)newData.clone();
                newData.clearDirtyFlag();
            }
            jd.setJobDataMap(newData);  //  set to new one
            
        
    }

}

然后，每次序列运行时所用的JobDetail，是存放在Store里面的克隆。

//  RAMJobStore.retrieveJob
public  JobDetail retrieveJob(SchedulingContext ctxt, String jobName,
        String groupName) {
    JobWrapper jw  =  (JobWrapper) jobsByFQN.get(JobWrapper.getJobNameKey(
        jobName, groupName));
     return  (jw  !=   null )  ?  (JobDetail)jw.jobDetail.clone() :  null ;  //  clone a new
}

问题很清楚了，存放在Store里面的JobDetail是初始对象的克隆，然后每个序列所用的JobDetail， 是Store里面的克隆，只有Stateful job，Store里面的JobDetail才更新。
最有Quartz里面使用的clone():

//  Shallow copy the jobDataMap.  Note that this means that if a user
//  modifies a value object in this map from the cloned Trigger
//  they will also be modifying this Trigger.
if  (jobDataMap  !=   null ) {
    copy.jobDataMap  =  (JobDataMap)jobDataMap.clone();
}

所以对于前面所讲的，修改bean的属性，会影响所有clone的对象，因此，我们可以将基本类型封装到一个bean里面，map里面存放的是bean，然后通过修改bean的属性，来达到影响下一个序列的目的。