1

The company I work for is considering the adoption and implementation of Workflow Foundation hosted in IIS for processing data. We are still designing our problem domain but a concern was raised that long running threads aren't ideal inside of IIS. Below are some of the assumptions we are making as Workflow is still a new technology to our group:

We are making a differentiation between a "long running process" and a "long running workflow" where a long running process is actively consuming CPU while a long running workflow is simply persisted for an indeterminable amount of time waiting for additional requests to complete it's work.

My question is: Is it a good practice to create a long running thread as a part of a Window Workflow hosted in IIS or should we implement long running processes outside of IIS by means of a traditional Windows Service?

Achilles
  • 11,165
  • 9
  • 62
  • 113
  • 1
    Long running threads on IIS are [typically a bad idea](http://stackoverflow.com/a/539000/87825). That being said, and if you want to consider using WF anyway, because you want, for example, to change it's logic regularly, visually and without full compilation/deploy, nothing stops you from running workflows on a Windows Service, executing them through [WorkflowInvoker](http://msdn.microsoft.com/en-us/library/system.activities.workflowinvoker.aspx) or [WorkflowApplication](http://msdn.microsoft.com/en-us/library/system.activities.workflowapplication.aspx). – Joao Mar 07 '13 at 22:36
  • 1
    If you still want Workflow Services capabilities (WCF-way), @Sentinel makes a good point but again, IIS isn't ideal for long running threads. – Joao Mar 07 '13 at 22:39

1 Answers1

1

Using AppFabric simply Persist your loop (I assume it must be a loop because otherwise a Receive or Delay will unload when Idle, so no long running process will occur), enable instance control and set the action on unhandled exception to Abandon (which restores the WF instance to the last persisted point).

In the application pool, disable recycling, rapid-fail etc. Whether or not it is good practice depends on many things, such as deployment concerns, if you want to interact with the process using wcf calls, if you want to easily scale, etc.. Personally, I don't like the hassle of Windows Services, and I think you always have to deal with unexpected process termination, so why not assume it will happen and go the IIS route with a safe persist point?

Sentinel
  • 3,582
  • 1
  • 30
  • 44