Creation of Multiple Workflow Runtime Instances within an AppDomain
There seems to be a lot of confusion on the forums regarding this particular topic. I have been playing around with WF since its CTP days, when we had this restriction saying that we could create one and only one instance of Workflow Runtime within an AppDomain. In fact even if I tried to create more than one instance within a single AppDomain it would result in an exception getting thrown. But in the final release this restriction has been removed (Please refer the link: http://support.microsoft.com/kb/935354). This means that now it’s possible to create more than one instance of the workflow runtime within a single AppDomain. But do I really need to create multiple instances of the workflow runtime? This is the question I am trying to answer and I would like people out there as well to let me know if they have actually had to do this in any of their application scenarios.
The ability to use multiple runtimes is useful when workflows need different execution environments. For example if we need to run two different workflows, one using the Default workflow scheduler service and the second one using the Manual workflow scheduler service and I want to externalize the configuration information, I can create two different instances of the workflow runtime and they can be configured with the required services by defining two separate configuration sections in the application configuration file as shown below.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section
name="ManualRuntimeSection"
type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection,
System.Workflow.Runtime, Version=3.0.00000.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<section
name="DefaultRuntimeSection"
type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection,
System.Workflow.Runtime, Version=3.0.00000.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</configSections>
<ManualRuntimeSection>
<Services>
<add type=
"System.Workflow.Runtime.Hosting.ManualWorkflowSchedulerService,
System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
useActiveTimers="true"/>
</Services>
</ManualRuntimeSection>
<DefaultRuntimeSection>
<Services>
<add type=
"System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService,
System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
maxSimultaneousWorkflows="3" />
</Services>
</DefaultRuntimeSection>
</configuration>
The above scenario can be achieved through code by actually using a single workflow runtime instance by programmatically adding and removing the services at runtime, but we would struggle to externalize the configuration information in that case.
But as a good practice, it’s always better to avoid creating multiple instances of the workflow runtime unless and until you have a requirement which compels you to do so. The basic reason being these instances are large and could eat up your valuable memory causing memory leaks.
In fact memory leak of WorkflowRuntime has been identified as a bug in V1 of WF (Please refer this link). Using a singleton WorkflowRuntime is your only mitigation right now. MS is going to fix the issue in the next release of WF.
Comments
Hi, but what about a scenario when I have 20 different workflows? How to avoid creating multiple workflow runtimes?
Posted by: Aleksey | November 19, 2007 01:25 AM
Aleksey,
Even if you have 20 or 'n' different workflows, it really doesn't mean that you need to create that many number of workflow runtime instances. You can use the same workflow runtime instance to start of all these workflow instances. For example, if you have 2 workflows say WFTypeA and WFTypeB, to create an instance for each of these on the same runtime instance. You would be writing the below piece of code:
runtime.CreateWorkflow(typeof(WFTypeA));
runtime.CreateWorkflow(typeof(WFTypeB));
these instances can be identified using their Workflow Instance IDs.
You need to have a singleton implementation for your Workflow Runtime instance so that we ensure that more than one workflow runtime instance does not get created.
Thanks.
Posted by: E.Krishna Kumar | November 20, 2007 04:29 AM
Ok, so it is possible to run multiple workflows from one workflow runtime, which makes sense to me. Have you created some sort of control class to manage workflow(possibly state machine workflows) administration?
Posted by: JJ | January 25, 2008 02:28 PM
Can anyone give me some good realworld realtime workflow examples?
Also, can workflow host series of workflows ?
Posted by: Ravi Santlani | March 27, 2008 11:26 AM
Ravi,
To me there is some kind of workflow, be it large or small, short or long-running, involved in almost every software application. A Leave Application System, an E-Commerce application, A batch processing application, banking applications all involve workflows. We have seen WF getting used in almost all these different kind of applications.
The second part of your question is not very clear to me. In WF, Workflows and Workflow Runtime are hosted by a host process and the runtime can instantiate and manage any of the hosted workflows. One workflow can even invoke another workflow as well.
Let me know if i have answered your question or you require some more information. Thanks.
Posted by: E.Krishna Kumar | March 28, 2008 06:59 AM
How do I add multiple ExternalDataExchangeServicetypes to this runtime then? Say I have two different workflow types in my app (State based) and they both raise different set of ExternalDataExchangeService type events. How do I add these two services now?
Posted by: Victor Miller | April 2, 2008 12:03 PM