好了，言归正传！！
DNN调度解决方案是在DNN2.1.1开始引进的，它通过提供一个线程池管理调度任务来实现了多线程调度服务。该线程池允许可重用在池中现有的线程，而不需要杀死线程，即而生成新线程的无效率做法。
无疑的，创建一个多线程的应用程序是比较繁琐的，你不得不费尽心思去防止不出现类似两个线程同时读写同一个对象的现象。为了达到实现一个可靠的多线程应用程序，DotNet中存在一些ReadWriteLock的实例去锁定和解锁你需要进行读写操作的对象于达到不出现死锁的瓶颈。
首先不妨先看看在Web.config文件里边DNN调度服务的相关信息：
属性设置：
debug – 若这个属性设置为true,则会产生一些有助于调试DNN调度服务的一些记录信息条目。当你在调试DNN调度程序时，这些会给你足够的信息，尽管调试多线程应用程序是一特繁琐的过程。
maxThreads – 设置调度服务具体在线程池中最大的线程数目，默认为-1，这意味这由调度服务程序自主决定（在调度服务中，默认最大为10）。若你设置该项为大于零的某个数目，则这就是线程池中最大的数目。
enabled – 调度服务开启属性，若设置为fasle,则意味着禁止所有的调度服务。
接着让我们看看DNN里是如何使用调度服务的，在顶端的页签菜单上能找到如：
点击Schedule,将进入Schedule页面，如下图，在这个页面上，你可看到哪个调度任务已被开启和禁止以及运行任务的频率，失效重试的时间间隔，下次开始启动调度服务时间。而在下表每个任务都有两个链接：a)编辑页面链接 b)查看历史链接 （在下边会有提到）
可通过点击在每个任务前边的编辑图标进入编辑该调度服务设置页面，如图：
参数设置如下：
1） Available Tasks 下拉框包括了所有在bin目录下程序集继承于DotNetNuke.Services.Scheduling.SchedulerClient的类，DNN通过发射机制实现之。
2） Schedule Enabled 是否开启或禁止该调度服务
3） Time Lapse 即是你想要调度任务运行的频率，以分钟/小时/天为单位
4） Retry Frequency 重试间隔时间，即是当该调度任务失败后，间隔一定时间即重起一次。
5） Retain Schedule History 由于每次任务执行时，数据库都会存储反映任务情况的记录及摘要（如果你看了上面的文章的话，你会发现调度任务执行时都会调用AddLogNode()方法），而这个字段的设置就是保留在数据库里记录的数目。
6） Run on Event 在此你可以设置调度服务在程序运行时开始启动，目前只有APPLICATION_START这个选项。
7） Catch up Enabled 当这个设置为true，如果你的任务是每十分钟调度一次的话，例如在调度期间由于某种原因突然中止了（比方说 服务器重起），当再次重启时，之前的所有失效任务都会被再次运行一次。举个例子，若你的调度服务中断了一个小时，则重启时它会执行之前失效的六次。而该设置为false的话则只会执行当前的一次。
8） Object Dependencies 既然调度服务是多线程的，故要避免出现死锁问题。所以设置一个依赖对象会防止其他任务跟其有执行冲突。例如，你有一个任务A,其操作关联User表，而同时任务B在更新User表。这时你必须设置它们有同样的依赖对象。(当然你也可设置多个依赖对象，比方说你可设置任务B的依赖对象为”Users,UsersOnline,Portals”。)这样当任务A运行时,任务B是不会运行的，因为它们有依赖冲突。只有当任务A完成了，任务Ｂ才会开始启动！
而在Schedule页面上，你还可以把鼠标移到左上角，这时你会看到如下菜单：
菜单列有一些链接，点击”View Schedule Status”即可进入察看调度服务状态页面，如下图。在这个页面你会看到当前的调度服务状态，比如有多少线程或哪些是激活的,你还可以开启或停止某项调度服务，还有就是能看到当前执行的及在队列中等待的调度任务。
若你点击”View Schedule History”链接则你可看到调度服务的历史记录，如图，包括开始，结束，持续时间，是否成功，下次执行时间以及一些相关执行摘要。
到此DNN调度管理解析研究告一段落了！！下次准备把对DNN的日志管理机制的心得添加上来！DNNNer,Good luck！！
最后随便提一下，在前边提到的调度服务的相关数据是存储在数据库的三个关联表里的，如图，而具体实现的提供者则在Web.config体现 。