为 WF 3.0/3.5 编写长时间运行的自定义活动的最佳实践
为 Workflow Foundation (3.0/3.5) 编写长时间运行的自定义活动的最佳实践建议 对于一个活动来说，完全在该活动的 Execute 方法中执行长时间运行的任务并不是一个好主意。 分配给工作流的单个线程将被阻止，这会阻止处理工作流的其他计划请求。
因此，对于长时间运行的任务，应该创建一个队列。 实际工作将由本地服务（在线程池线程上运行）完成。 该服务通过先前的工作流队列将工作结果传递给等待活动。
所以我的问题是，到底什么可以量化任务的长时间运行？ 是处理时间的问题吗？ 什么时候应该创建队列以及什么时候仅使用本地服务就足够了？
感谢您的任何澄清。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您需要什么样的可靠性将主要决定这一点。 我发现可以安全地假设，任何涉及与一个或多个外部系统（无论只是电子邮件）通信的任务都应该在处理时考虑到一定的可靠性，即之间的持久存储。
长时间运行并不是什么大问题，而是如果您在某个时刻无法从故障中恢复会发生什么。 这就是为什么我在处理工作流时依赖数据库事务来提交或回滚工作流状态。
我认为任何可能阻塞超过 2 分钟的操作都属于长时间运行。 根据我有多少可用的免费完成端口，我什至可能不想等待那么久，但这更多的是负载平衡的事情。 让您的工作流程运行时保持稳定但不阻塞；）
编辑
那 2 分钟的事情来自 RFC 793，它规定 TCP 会话的空闲时间不应超过 2 分钟。 我认为，如果我的系统正在与您的系统对话，并且需要超过 2 分钟才能完成，那么它们不应该等待对方完成。
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.