原来配置的Quartz是通过spring配置文件生效的,发现在非集群式的服务器上运行良好,但是将工程部署到水平集群服务器上去后改定时功能不能正常运行,没有任何错误日志,于是从jar包、JDK版本、cronExpression到服务器类型,甚至查到了服务器操作系统的类型,都没能找到解决的办法,后来才知道是集群惹的祸!
详细步骤如下:
1、 按照Quartz集群工作原理
图:表示了每个节点直接与数据库通信,若离开数据库将对其他节点一无所知
在数据库中建表。建表模版在Quartz包下docs/dbTables下,选择相应的数据库和版本即可。DB2_V8的11个Table列表如下:
QRTZ_JOB_LISTENERS
QRTZ_TRIGGER_LISTENERS
QRTZ_FIRED_TRIGGERS
QRTZ_PAUSED_TRIGGER_GRPS
QRTZ_SCHEDULER_STATE
QRTZ_LOCKS
QRTZ_SIMPLE_TRIGGERS
QRTZ_CRON_TRIGGERS
QRTZ_TRIGGERS
QRTZ_JOB_DETAILS
QRTZ_CALENDARS
QRTZ_BLOB_TRIGGERS
2、 配置数据库连接池,如果spring已经配置则不需要再另行配置,只需在后面配置的applicationContext-quartz.xml引入即可。
applicationContext.xml:
dataConfig.properties:
3、 配置quartz.properties
org.quartz.scheduler.instanceName属性可为任何值,用在 JDBC JobStore 中来唯一标识实例,但是所有集群节点中必须相同。 org.quartz.scheduler.instanceId 属性为 AUTO即可,基于主机名和时间戳来产生实例 ID。 org.quartz.jobStore.class属性为 JobStoreTX,将任务持久化到数据中。因为集群中节点依赖于数据库来传播 Scheduler 实例的状态,你只能在使用 JDBC JobStore 时应用 Quartz 集群。这意味着你必须使用 JobStoreTX 或是 JobStoreCMT 作为 Job 存储;你不能在集群中使用 RAMJobStore。 org.quartz.jobStore.isClustered 属性为 true,你就告诉了 Scheduler 实例要它参与到一个集群当中。这一属性会贯穿于调度框架的始终,用于修改集群环境中操作的默认行为。 org.quartz.jobStore.clusterCheckinInterval 属性定义了Scheduler 实例检入到数据库中的频率(单位:毫秒)。Scheduler 检查是否其他的实例到了它们应当检入的时候未检入;这能指出一个失败的 Scheduler 实例,且当前 Scheduler 会以此来接管任何执行失败并可恢复的 Job。通过检入操作,Scheduler 也会更新自身的状态记录。clusterChedkinInterval 越小,Scheduler 节点检查失败的 Scheduler 实例就越频繁。默认值是 15000 (即15 秒)。
quartz.properties:
4、 配置applicationContext-quartz.xml
5、 配置Job任务注意:加入定时任务有两种方式:
① 继承QuartzJobBean的类,重写executeInternal(),详细写法:
② 用org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean指定类和方法,但是直接使用会报java.io.NotSerializableException异常,一般用网上流传的(需要将两个类copy到自己的工程下,要有springJAR包,Job需要持久化到数据库中,SimpleService必须实现Serializable)frameworkx.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean,可以参考: http://jira.springframework.org/browse/SPR-3797。详细写法:
6、 配置到spring配置文件,自动调度任务。
7、 测试用例
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/liaowu010/archive/2010/08/31/5853683.aspx