How many workflow runtimes should there be running for in an Asp.Net application?

Question

Hello Gurus,

There doesn't seem to be many Windows Workflow Foundation gurus out there :(

Here are couple of challenges that I face:

How many workflow runtimes should there be running for in an Asp.Net MVC application? One per application, per session or per request?

How frequently should the workflow runtime be started and stopped? Once per application instance, once per session or once per request?

What are the pros and cons of doing one or another in the above options?

Any comments or suggestions are welcome,

Thanks,

Cullen

Answer 1

How many workflow runtimes should there be running for in an Asp.Net MVC application?
one per application, unless you need more for scalability purposes (too many requests)

How frequently should the workflow runtime be started and stopped?
typically, once per application instance

The pro's and con's are trivial, you can scale better with more session requests and instances, but it takes more overhead to manage them all.

Your best bet is to use just enough of what you need and grow later if necessary.

Answer 2

You would normally only run one workflow runtime per application. It is possible to define more than one and there may be some complex scenarios where that is desirable but its highly unlikely. I can't see any scenario where multiple runtimes for the same configuration would be run in the same process.

For a web hosted workflow you really need the SqlWorkflowPersistenceService. IIS expects to be able to recycle an application pool with minimul impact on the application. Hence you need idled workflows to be persisted so that they survive such recycles.

On a similar note you should use the ManualWorkflowSchedulerService which plays nice with ASP.NET use of threads, its also really handy in being able to perform end-to-end processing of a request to a response through workflow on a single thread. Just be sure to include the useActiveTimers="true" attribute so that delay activities work.

In line with the above you need to be sure that any active workflow does not take longer to complete or go idle than the application pool's shutdown time limit. Otherwise on recycle IIS may force the process to terminate before a workflow has persisted.

As to starting and stopping the workflow, its again difficult to see a scenario where you wouldn't just want it to start on application start and remain running. I guess if you have a workflow which never idles but just runs from beginning to end and you only run such workflows very occasionally then it might be simpler to start the runtime and the end it afterward. However even that can get messy, I wouldn't bother just start it on app start and be done with it.