四. 监听 Trigger 事件
正如 JobListener, org.quartz.TriggerListener 接口也包含一系列给 Scheduler 调用的方法。然而，与 JobListener 有所不同的是， TriggerListener 接口还有关于 Trigger 实例生命周期的方法。代码 7.5 列出了 TriggerListener 接口的方法。
代码 7.5. org.quartz.TriggerListener 接口的方法 阅读全文 >>
“天时、地利、人和，三者不得，虽胜有殃。” 《荀子•天论》，天时地利人和俱在，民主才能水到渠成。
天时
中国人是一个历史感很强的国家，一提就是几千文明史，相对空间感却比较差，而美国却相反，他们时间感比较差，空间感却很强，如果说历史上丝绸之路、郑和下西洋算广阔的空间感，接下来就是闭关锁国，从此失去许多发展机会，失去五六百年的机遇。中国这个有着漫长岁月沉淀的国家,主流文化一直信奉着"学而优则仕"的思想!读书就是为了做官,几千年来中国的百姓好象都是这么想的，统治者为中国古代知识分子设计唯一的光明出路——学而优则仕。 阅读全文 >>
魔高一尺，道应比其高一丈
Oracle SQL的优化规则：
用IN写出来的SQL的优点是比较容易写及清晰易懂，但是用IN的SQL性能总是比较低的，从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别：
ORACLE 试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用 IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。 阅读全文 >>
三. 监听 Job 事件
org.quartz.JobListener 接口包含一系列的方法，它们会由 Job 在其生命周期中产生的某些关键事件时被调用。JobListener 可用的方法显示在代码 7.1 中。
代码 7.1. org.quartz.JobListener 接口中的方法
|
1 2 3 4 5 6 7 8 |
public interface JobListener { public String getName(); public void jobToBeExecuted(JobExecutionContext context); public void jobExecutionVetoed(JobExecutionContext context); public void jobWasExecuted(JobExecutionContext context, JobExecutionException jobException); } |
第七章. 实现 Quartz 监听器
在某个所关注事件发生时，监听器提供了一种方便且非侵入性的机制来获得这一通知。Quartz 提供了三种类型的监听器：监听 Job 的，监听 Trigger 的，和监听 Scheduler 自已的。本章解释如何应用每一种类型来更好的管理你的 Quartz 应用，并获悉到什么事件正在发生。
一. 监听器作为扩展点
术语 "扩展点" 在软件开发中用于指示框架或应用的某个位置，在这一位置在创建者期望用户扩展或定制这一框架来适合于他们的需要。(你也将会听到 hook(钩子) 一词，是一样意思的) 阅读全文 >>
直接以一个例子在说明，如DB2中有一个简单存储过程 selectAllUsers
|
1 2 3 4 5 6 7 |
CREATE procedure selectAllUsers DYNAMIC RESULT SETS 1 BEGIN DECLARE temp_cursor1 CURSOR WITH RETURN TO CLIENT FOR SELECT * FROM test; OPEN temp_cursor1; END; |
映射文件中关于存储过程内容如下 阅读全文 >>
十三. 改善持久性 JobStore 的性能
当在只有最少量时间做任何相关事情的时候，性能是一个广受人瞩目的课题。作为有经验的开发者，我们知道从项目之初它就成为一个需要考虑的事。
在使用 Quartz 的 JobStore 时，最大的关注面就是有关于与关系型数据库的交互。数据库 I/O(就像文件 I/O) 通常不是很快。你可以通过采取一些措施，如调优 SQL、增加索引和操作表和列等来改善性能。因为性能问题在写 Quartz 框架的时候就已有考虑到，而你又不想在未出现实际的性能问题时扎入到 Quartz 中做些手脚，那么可试图通过配置来解决它，或者尝试所有可能的方式，只要不是维护源代码。最好的消息是 Quartz 是开源的，你完全可以窥入其中了解它做了什么和如何实现的。假如你不喜欢它现有的查询数据库的方式，你有权去修正它。不过，在你采取行动之前，确定检查了 Quartz 论坛上的用户和开发者，看看是否其他人也遇到了相关的问题并浏览推荐的做法。 阅读全文 >>
十二. 为 JobStoreCMT 配置数据源
跟 JobStoreTX 一样，我们需要配置一个 Datasource 才能使用 JobStoreCMT。然而，JobStoreCMT 需要两个 Datasource 而不是像 JobStoreTX 只要一个。其中一个 Datasource 和我们为 JobStoreTX 设置的类同：作为不受管理的数据源。同时呢，我们还需配置第二个数据源，是作为受管理的数据源，它由应用服务器来进行管理。
| 为什么 JobStoreCMT 需要两个 Datasource 呢？JobStoreCMT 的原始作者，Jeffrey Wescott，设计 JobStoreCMT 使用一个标准的 JDBC 连接来做它“自己的工作”，同时，代表客户端(如部署 Job) 的工作在执行时是使用一个在容器控制之下有自身事物的 JDBC 连接。即使 Quartz 处在一个大事物中，这种设计也允许用户与 Quartz 交互，而无需 JobStoreCMT 非得使用应用服务器的事物管理器(例如，经由 UserTransaction) 在做自己内部工作时(如处理已错过执行的 Trigger) 来创建和终止事物。如果是 JobStoreCMT 使用 UserTransation 只给它配置一个数据源，从配置方面来看确实方便。然而，在相比于别的特性需求和改进的必要性时，作此变化并不会成为团队中首要的问题，因而 JobStoreCMT 还是继续要两个数据源。 |
十. 使用数据库存储 Scheduler 信息
·加载 Job 到数据库中
在前面有一节，"使用内存存储 Scheduler 信息"，我们谈到关于在使用 RAMJobStore 时如何加载 Job 和 Trigger 信息到内存中。那么 Job 和 Trigger 又是如何加载到数据库中的呢？存在以下几个方法把 Job 信息存入到数据库：
· 在你的程序中加入 Job 信息
· 使用 JobInitializationPlugin
· 使用 Quartz Web 应用程序
我们在前面的 RAMJobStore 章节中讨论过前面两种途径。当它们用于 JDBC JobStore 时，并没有多大不同，只些许例外。首先，你需要知道，当使用这两个方法式，Job 信息是在数据库中的。甚至在你停止了程序后，这些信息仍然保留在数据库中。甚至是你不在你的程序中使用 JobInitializationPlugin 时，这些信息也还在数据库中。基于这一点，它是会从数据库中找寻 Job 信息。第八章涵盖了 JobInitializationPlugin 和常用的 Quartz 插件。 阅读全文 >>