Jason Foster's Blog - wonderings

Well, it's kind of a hack but it works.  If your workflow runtime host goes away for whatever reason, whether it be ASP.NET, a Forms or Console application, or a Windows service you can peer into the persistence database using the LoadExpiredTimerWorkflowIds method on the SqlWorkflowPersistenceService instance associated with your runtime.  The code snippet below gets the persistence service instance from the runtime and resumes the processing on each workflow.  This allows the timer events to fire which in turn will cause your workflows to flow once more.

ReadOnlyCollection<SqlWorkflowPersistenceService> sqlSvc = 

   _workflowRuntime.GetAllServices<SqlWorkflowPersistenceService>();

IList<Guid> readyWorkflows = sqlSvc[0].LoadExpiredTimerWorkflowIds();

foreach (Guid wfGuid in readyWorkflows)

{

   _workflowRuntime.GetWorkflow(wfGuid).Resume();

}

I haven't fully tested it in a practical sense where I've got many runtimes sharing a persistence repository but I'll know more as the week progresses.

Matt Milner posted in the MSDN Workflow Foundation forum that the LoadIntervalSeconds setting on the SqlWorkflowPersistenceService will automatically load any persisted workflows based on that interval.  So the only reason to directly resume the workflows is if you feel that delay would be a problem for some reason.  Thanks, Matt.