R – Windows Workflow: “singleton”-style workflow

Its quite likely that the app domain recycling is a large part of your problem. IIS will recycle an AppDomain as soon as the last request is finished. It does not however see code running on another thread as part of that request. That is one of main reasons for using the ManualWorkflowSchedulerService when hosting in IIS. But when you use the active timers option it still uses a background thread to execute workflow activities.

Also make sure you unload workflows as soon as they go idle. The easiest way of doing so is using the UnloadOnIdle setting on the SqlWorkflowPersistenceService.

The PersistenceService checks for workflows with an expired ownership but only at startup time. So most likely restarting the IIS worker process will also restart old workflows without any extra work. But as this is the case of new problems..... Just clearing out the old ownership should also do the trick. In that case the PersistenceService should just reload the workflows at the next time. The only trick is to know which runitme ID is old and which isn't (the property holding the value is not public).

Another thing to make sure of is that the IIS worker process is reloaded. If this isn't done there is no WF runtime so it cannot check for expired timers. It sounds like you have this covered but just in case.

There are a few ways you can do this.

First option is to use the WorkflowPersistenceService itself and do something like:

var persistenceService = new SqlWorkflowPersistenceService("<<connection string>>");
var persistedWorkflows = persistenceService.GetAllWorkflows();
foreach (var persistedWorkflow in persistedWorkflows)
{
    var workflowInstance = workflowRuntime.GetWorkflow(persistedWorkflow.WorkflowInstanceId);
    var workflowDefinition = workflowInstance.GetWorkflowDefinition();
    Console.WriteLine(workflowDefinition.GetType().FullName);
}

Easy to do as you are already using the SqlWorkflowPersistenceService but it has the drawback of having to load all workflow instances into memory and you are responsible for removing them from memory.

The second option is to use workflow tracing:

    var trackingQuery = new SqlTrackingQuery("<<connection string>>");
    var queryOptions = new SqlTrackingQueryOptions()
    {
        WorkflowStatus = WorkflowStatus.Running
    };
    var runningWorkflows = trackingQuery.GetWorkflows(queryOptions);
    foreach (var runningWorkflow in runningWorkflows)
    {
        Console.WriteLine(runningWorkflow.WorkflowType);
    }

The advantage is you don't need to load the actual workflow definition into memory just to check it's type. The drawback is you have to add the SqlTrackingService as well with it's own database adding complexity and overhead.