Using DefaultWorkflowSchedulerService

DefaultWorkflowSchedulerService is used by the workflow runtime engine by default. It creates and manages the threads that run workflow instances in an asynchronous manner on the workflow runtime engine. Workflows that are waiting to run are stored in the internal queue of the DefaultWorkflowSchedulerService . When the DefaultWorkflowSchedulerService wants to start a workflow, a thread is acquired from the .NET Framework thread pool and used to run the workflow. The MaxSimultaneousWorkflows property determines how many simultaneous threads the scheduler service will allow at one time. If the limit is four, for example, the DefaultWorkflowSchedulerService will acquire up to four threads from the .NET Framework thread pool to execute the workflows. If four workflows are already running, additional work items (workflows) are placed in the queue and eventually executed as threads become available. The following figure shows how the DefaultWorkflowSchedulerService executes workflows in an asynchronous manner.

You can set the maximum number of workflow instances that can be active at any one time by passing a parameter to the DefaultWorkflowSchedulerService constructor or by using an application configuration file. Task 1: Configure Runtime Services Using Code shows how to configure the DefaultWorkflowSchedulerService class by using the constructor. Task 2: Configure Runtime Services using App.Config shows the same configuration of the DefaultWorkflowSchedulerService but uses an application configuration file.

Note

Setting MaxSimultaneousWorkflows to a high value could cause the .NET Framework thread pool to starve. This could cause time-outs when a persistence service tries to complete a persistence transaction because Transaction objects also use the .NET Framework thread pool.

See Also

Reference

DefaultWorkflowSchedulerService
MaxSimultaneousWorkflows

Concepts

Windows Workflow Scheduling Services