ASP.NET and Windows Workflow's (WF) - do we need to stick it in the Application state?

Question

I've been trying to use WF in my ASP.NET application (actually, it's ASP.NET MVC ... but the fact that it's MVC instead of WebForms should not matter at all).

Now, I can run the WF and it works fine, etc, but it kicks off ASYNCHRONOUSLY, so any results from the WF (good or bad) get lost page life cycle.

I found an MSDN article that says that in ASP.NET applications, we need to

• Put the WorkflowRuntime into the Application state
• The WorkflowRuntime instance has a ManualWorkflowSchedulerService added to it (whatever that is).
• Use this application state workflow instance when required.

This is different than how I learned to do it:

• Make the WorkflowRuntime a static object, that is first created when required.
• Use this static WorkflowRuntime instance on the new workflow you're going to run.

So ... which way is better? Do we need to stick it into the application? What are the differences between the two?

I understand there's actually TWO questions here...

• Application state vs static object (using lock/null or double null checking)
• DefaultWorkFlowSchedulerService vs ManualWorkFlowSchedulerService

cheers!

EDIT:

• First question is answered here.
• Second question is answered below.

Answer 1

I am not sure about your first question (although I suspect that they are equivalent). However, I am sure for the second question: You must definitely go with the ManualWorkflowSchedulerService. The main reasons are the following:

• It's the only way to block the execution of the host application until the workflow instance becomes idle. Note that you have to explicitly use the RunWorkflow method.
• ManualWorkflowSchedulerService reuse the thread that made the ASP.NET Web request to run the workflow instance. This ensures that at any time, the number of active threads in the workflow runtime equals the number of active Web requests in the ASP.NET process.

Check this sample for more.