使用Monitor.Enter在WF线程中超时（在ASP.NET中使用带有默认调度程序的WF3.0） [英] use of Monitor.Enter in WF threads timing out (using WF3.0 in ASP.NET with default scheduler)

问题描述

我的服务器负载不足，有100个用户，还有100个WF正在运行。我认为现在是时候将我的WF转移到Windows服务中了，这是计划在下一个版本中使用的，但是现在我遇到了一个大问题，需要知道从哪里开始寻求解决它。
我使用Context模式将数据库连接与我工作流程中正在运行的执行线程相关联，例如：

My server is under load, with 100's of users, and 100's of WFs running.  I think the time is right to move my WFs into a windows service actually, and that is planned for next release, but for now I ave a big problem and need to know where to start looking to solve it.

I use an Context pattern to associated a database connection with a running thread of execution in my workflows,  eg:

using (new EntityContext()){

     // do stuff
     SqlConnection currentConn = EntityContext.GetAssociatedConnection();   // get the connection associated with this managed thread
}

推荐答案

WF或IIS / ASP.NET没有任何改变Monitor.Enter和Exit行为的信息。

一些可能性：
*你有一个锁泄漏...是否有一个代码路径（或错误路径）可能会调用回路而不会调用退出？一般情况下，建议尽可能使用lock语句来避免这种情况。
*在长时间运行的工作中你持有锁。像I / O这样的事情可能需要很长时间，尤其是在您谈论访问负载很重的SQL数据库时。在进行此类工作时应避免握住锁。
*机器过载，以至于需要很长时间才能锁定。低内存和许多线程的某种组合可能（但不一定可能）导致足够的颠簸，导致没有任何线程正在向前发展。

调试死锁的几个资源：
http://dotnetdebug.ne​​t/2005 / 06/07 / identify-deadlocks-in-managed-code / comment-page-1 / （描述使用WinDbg查看同步块）
http://msdn.microsoft.com/en-us/library/ms954592.aspx （使用WinDbg查看底部的一些有趣内容线程状态）

There's nothing about WF or IIS/ASP.NET that changes the behavior of Monitor.Enter and Exit.

Some possibilities:
* You have a lock leak somewhere ... is there a code path (or an error path) that could potentially call Enter without ever calling Exit?  In general it is recommended to use the lock statement when possible to avoid this scenario.
* You're holding the lock while doing long running work.  Things like I/O can take a long time especially when you're talking about accessing a heavily loaded SQL database.  You should avoid holding the lock while doing this type of work.
* The machine is so overloaded that it really takes that long to get access to the lock.  It is possible (but not necessarily likely) that some combination of low memory and lots of threads can cause enough thrashing that none of the threads are making much forward progress.

A couple of resources on debugging deadlocks:
http://dotnetdebug.net/2005/06/07/identifying-deadlocks-in-managed-code/comment-page-1/ (describes using WinDbg to look at sync blocks)
http://msdn.microsoft.com/en-us/library/ms954592.aspx (shows some interesting stuff toward the bottom using WinDbg to examine thread states)

这篇关于使用Monitor.Enter在WF线程中超时（在ASP.NET中使用带有默认调度程序的WF3.0）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！