SharePoint工作流中暂停动作会延迟恢复问题

                                                                            工作流中暂停动作会延迟恢复问题

1. 很多时候在我们使用SharePoint Designer和Visual Studio去设计工作流的时候，需要在里面添加Pausing for duration的动作，这样做很多时候是为了避免自定义开发的工作流和系统的一些event receiver冲突，因为在SharePoint中有很多自带的event receiver,当上传文档或者新建一个列表项之后，会触发很多系统自带的event receiver，同时也会触发相应的工作流，如果两者同时更新一个item的时候，这样就会出现更新冲突，所以很多时候，自定义功能会给系统自带功能让路，因为我们不能控制系统自带功能，确实可以调整自定义功能。

2. 在SharePoint中一个有两种方式去执行工作流：

1) 同步方式：这种方式是在w3wp.exe中运行工作流的事件，处理相应的操作，也就是说是在这个进程里面开启一个新的线程，立即执行。

2) 异步方式：这种方式是在owstimer.exe中运行工作流事件，这种有一定的延迟性，默认是5分钟，因为owstimer.exe中运行很多timer job，默认工作流的timer是每5分钟执行一次，有了这个进程是为了缓解w3wp的压力

3. 我们再回头来说一下pausing for duration，当工作流执行暂停动作的时候，当前工作流事件线程挂起，所以一般恢复执行的时间： 暂停时间< 恢复时间< 暂停时间+工作流timer job的间隔

以上是在正常情况下的恢复时间，很多时候这个工作流恢复时间会加长，有的一天，两天，甚至1周，2周，最长的一个月都有可能，这是为什么呢？

其实这要从内部进行解释，一个一个工作流事件都是在thread里面执行的，当执行暂停动作的时候，也就是说当前thread挂起，不再占用CPU时间片，那么优先级相对也就低了。 这个时候有很多正在运行的工作流或者其他的任务占用CPU，而且他们thread的优先级又高于这个暂停的工作流优先级，所以CPU一直没有倒出时间去执行这个暂停动作。导致这个暂停动作一直在等待，直到CPU恢复这个线程。

4. 基于以上情况，也就说明系统一直处于忙碌状态，系统资源不足以按时处理任务，所以我们要查看系统性能，尽量去优化系统性能，让系统能够更快的处理任务，才能保证暂停按时恢复