title: ASP.NET and Windows Workflow's (WF) - do we need to stick it in the Application state?
body: <p>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).</p>
  
  <p>Now, I can run the WF and it works fine, etc, but it kicks off ASYNCHRONOUSLY, so any results from the WF (good <em>or</em> bad) get lost page life cycle.</p>
  
  <p>I found an <a href="http://msdn.microsoft.com/en-us/library/aa349445.aspx" rel="nofollow noreferrer" title="please click me!">MSDN article</a> that says that in ASP.NET applications, we need to </p>
  
  <ul>
  <li>Put the <code>WorkflowRuntime</code> into the Application state</li>
  <li>The <code>WorkflowRuntime</code> instance has a <code>ManualWorkflowSchedulerService</code> added to it (whatever that is).</li>
  <li>Use this application state workflow instance when required.</li>
  </ul>
  
  <p>This is different than how I learned to do it:</p>
  
  <ul>
  <li>Make the WorkflowRuntime a static object, that is first created when required.</li>
  <li>Use this static WorkflowRuntime instance on the new workflow you're going to run.</li>
  </ul>
  
  <p>So ... which way is better? Do we need to stick it into the application? What are the differences between the two?</p>
  
  <p>I understand there's actually TWO questions here...</p>
  
  <ul>
  <li>Application state vs static object (using lock/null or <a href="http://en.wikipedia.org/wiki/Double_checked_locking_pattern" rel="nofollow noreferrer" title="click me!!">double null checking</a>)</li>
  <li><em>DefaultWorkFlowSchedulerService</em> vs <em>ManualWorkFlowSchedulerService</em></li>
  </ul>
  
  <p>cheers!</p>
  
  <p>EDIT:</p>
  
  <ul>
  <li>First question is answered <a href="https://stackoverflow.com/questions/303725/aspnet-application-state-vs-a-static-object" title="go! click click click">here</a>.</li>
  <li>Second question is answered below.</li>
  </ul>