Best practices for writing long running custom activities for Workflow Foundation (3.0/3.5) suggest that it is not a good idea for an activity to perform a long-running task entirely within the Execute method of the activity. The single thread allocated to the workflow would be blocked, which prevents the processing of other scheduled requests for the workflow.
So for long running tasks, a queue should be created. The actual work will be done by a local service (running on a thread pool thread). This service passes the result of the work to the waiting activity via the previously workflow queue.
So my question is, what exactly quantifies a task as long running? Is it a matter of processing time? When should one create a queue and when is just using a local service sufficient?
Thanks for any clarification.
What kind of reliability you need will mostly govern this. I find it safe to presume that any task which involves communicating with one or more external systems (be it just e-mail) should be handled with some reliability in mind, i.e. persistent storage in between.
Long running is not so much of an issue as what would happen if you fail to recover from a failure at some point. This is why I rely on database transactions to commit or rollback workflow state as the workflow is being processed.
I would consider any operating which can potentially block for more than 2 minutes as long running. And depending on how many free completion ports I have available I might not even want to wait that long but this is more of a load balancing thing. Keep your workflow runtime crunching but not blocking 😉
EDIT
That 2 minute thing comes from RFC 793 which dictates that no TCP session should remain idle for more than 2 minutes. I figured that if my system is talking to your system and its taking more than 2 minutes to complete they shouldn’t be waiting on each other to finish.