【发布时间】：2014-07-01 22:18:17
【问题描述】：
目前在 ASP.NET 请求中使用实体管理器的建议似乎是将AuthorizedThreadID 属性设置为NULL（参考1 和2）。虽然这有效，但似乎这正在关闭一个非常重要的“安全网”。虽然我非常努力地以线程安全的方式使用实体管理器，但如果我弄错了，拥有这个安全网仍然很好......所以我宁愿不必将其设置为 NULL .
在 ASP.NET 世界中，仍然大致只有一个执行线程 - 只是当您执行异步工作时实际线程可能会发生变化。我能想到几个可能的解决方案：
-
EntityManager.SafeThreadingCheck()方法具有某种额外的魔力来支持 ASP.NET 请求。我可以理解 IdeaBlade 可能不想这样做......这导致我选择第二个选项...... -
EntityManager为我提供了一些扩展点来提供我自己的SafeThreadingCheck()版本，我可以在其中实现特殊的魔法来验证实体管理器在请求线程上是否仍然“逻辑上”。我可能需要在这里做一些奇怪的事情，但我认为这不会非常复杂。 - 我尝试使用其他扩展点来检测何时应该调用我自己的
FancySafeThreadingCheck()方法。这样做的缺点是我必须尝试挂接到所有必要的地方，而现有的SafeThreadingCheck()方法已经在最佳时间从所有必要的地方被调用（大概）。
我可以理解这可能不是最高优先级的功能请求，但它似乎也不会太难（至少对于选项 #2）。或者也许还有其他一些可能更好的解决方法？我的最终目标是避免关闭此安全检查...我愿意选择到达那里。
【问题讨论】：
-
我过去曾认为 AuthorizedThreadId 逻辑是一种天真的尝试来强制执行线程关联。 EntityManager 并不真正需要线程关联，但确实需要线程安全访问。我们可以看看选项 2 - 可能使方法虚拟化。
-
谢谢。知道您何时可能对此有更新吗？使方法虚拟化可能是最简单的，但对我们来说并不理想。我们经常被“标准”EntityManager 困住……尤其是对于服务器端调用（如 InvokeServerMethod 调用）——在这种情况下，“服务器实体管理器”只是一个普通的 EntityManager，而不是我们从 EntityManager 继承的自定义类。相反，如果有一个我们可以订阅的事件？或者可能是一种将自定义委托传递给现有实体管理器的方法？
-
自定义委托方法可能是最好的。我们可以在 7.2.4 版本中使用它——我还没有具体的日期。
-
这是个好消息。我们可以等到7.2.4。现在，我们将继续将 AuthorizedThreadID 设置为 null。如果你把这些 cmets 做成答案，我可以接受。
标签： c# asp.net multithreading devforce