odbc连接scan ip_weblogic连接scan ip_weblogic数据源连接池(7)

在Quartz 1.5之后，JobDataMap在 Trigger 级也是可用的。它的用途类似于Job级的JobDataMap，支持在同一个JobDetail上的多个Trigger。

伴随着加入到 Quartz 1.5 中的这一增强特性，可以使用 JobExecutionContext 的一个新的更方便的方法获取到 Job 和 Trigger 级的并集的 map 中的值。

这个方法就是getMergedJobDataMap() 取job 和 Trigger级的并集map，它能够在 Job 中使用。管法推荐使用这个方法.

* 实际使用中trigger级别有时取不到map中的值, 使用getMergedJobDataMap 可以获取到(官方推荐此方法).

有状态的Job: org.quartz.StatefulJob 接口

当需要在两次 Job 执行间维护状态，使用StatefulJob 接口.

Job 和 StatefulJob 在框架中使用中存在两个关键差异。

(一) JobDataMap 在每次执行之后重新持久化到 JobStore 中。这样就确保你对 Job 数据的改变直到下次执行仍然保持着。

(二) 两个或多个有状态的 JobDetail 实例不能并发执行。保证JobDataMap线程安全

注意:实际使用时使用jobStoreTX/jobStoreCMT ,StatefulJob,大量的trigger对应一个JobDetail的情况下Mysql会产生锁超时问题.

中断 Job

Quartz 包括一个接口叫做 org.quartz.InterruptableJob，它扩展了普通的 Job 接口并提供了一个 interrupt() 方法：

没有深入研究,只知道 Scheduler会调用自定义的Job的 interrupt()方法。由用户决定 Job 决定如何中断.没有测试!!!

job的特性

易失性 volatility

一个易失性的 Job 是在程序关闭之后不会被持久化。一个 Job 是通过调用 JobDetail 的 setVolatility(true)被设置为易失.

Job易失性的默认值是 false.

注意:只有采用持久性JobStore时才有效

Job 持久性 durability

设置JobDetail 的 setDurability(false)，在所有的触发器触发之后JobDetail将从 JobStore 中移出。

Job持久性默认值是false.

Scheduler将移除没有trigger关联的jobDetail

Job 可恢复性 shuldRecover

当一个Job在执行中，Scheduler非正常的关闭，设置JobDetail 的setRequestsRecovery(true) 在 Scheduler 重启之后可恢复的Job还会再次被执行。这个

Job 会重新开始执行。注意job代码事务特性.

Job可恢复性默认为false，Scheduler不会试着去恢复job操作。

图为表述没有执行完成的job记录

Scheduler 中移除 Job

移除所有与这个 Job 相关联的 Trigger；如果这个 Job 是非持久性的，它将会从 Scheduler 中移出。

更直接的方式是使用 deleteJob() 方法,它还会删除所有与当前job关联的trigger

public boolean deleteJob(String jobName, String groupName) throws SchedulerException;

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-29777-7.html