如何NOLOCK在Entity Framework上使用该功能？XML是唯一的方法吗？
CallContext和ThreadStatic有什么区别？
我知道在ASP.NET环境中,存储在CallContext中的数据可以在整个请求中持久存在,直到它结束,而ThreadStatic可能会或可能不会工作,因为请求可能会切换线程.我还了解到HttpContext是使用CallContext在内部存储的.
在常规应用程序中,它们似乎都在同一个线程调用中持久存在.什么时候不是这样的？
编辑:在评论中我了解到调用上下文是线程静态存储的抽象.ASP.NET框架显式地将数据从一个线程移动到下一个处理一个请求的线程.其他想要提供线程敏捷性的框架可以对上下文存储执行相同的操作.
我自己写了一个多线程随机生成器
public static class MyRandGen
{
private static Random GlobalRandom = new Random();
[ThreadStatic]
private static Random ThreadRandom = new Random(SeedInitializer());
private static int SeedInitializer()
{
lock (GlobalRandom) return GlobalRandom.Next();
}
public static int Next()
{
return ThreadRandom.Next();
}
}
但是,它在抛出Next()时抛出了NullReferenceException,我不明白.这种初始化ThreadStatic字段是否被禁止？
我知道我可以检查每次都是否已初始化该字段,但这不是我正在寻找的解决方案.
在这个问题中,Stephen Cleary接受的答案是LogicalCallContext无法正常使用异步.他还在这个 MSDN主题中发布了它.
LogicalCallContext保存一个Hashtable,存储发送到CallContext.LogicalGet/SetData的数据.它只是这个Hashtable的浅层副本.因此,如果您在其中存储可变对象,则不同的任务/线程将看到彼此的更改.这就是Stephen Cleary的示例NDC程序(在MSDN线程上发布)无法正常工作的原因.
但是AFAICS,如果你只在Hashtable中存储不可变数据(可能通过使用不可变集合),那应该有效,让我们实现一个NDC.
然而,Stephen Cleary也在接受的答案中说:
CallContext不能用于此.Microsoft特别建议不要使用CallContext进行远程处理以外的任何操作.更重要的是,逻辑CallContext不了解异步方法如何早期返回并稍后恢复.
不幸的是,该建议的链接已关闭(找不到页面).所以我的问题是,为什么不推荐这个？为什么我不能以这种方式使用LogicalCallContext？说它不理解异步方法是什么意思？从调用者的POV,他们只是返回任务的方法,不是吗？
ETA:另见其他问题.在那里,Stephen Cleary的答案说:
你可以使用CallContext.LogicalSetData和CallContext.LogicalGetData,但我建议你不要,因为当你使用简单的并行性时它们不支持任何类型的"克隆"
这似乎支持我的情况.所以我应该能够建立一个NDC,这实际上是我需要的,而不是log4net.
我写了一些示例代码,它似乎工作,但仅仅测试并不总是捕获并发错误.所以,由于其他帖子中有提示这可能不起作用,我仍然会问:这种方法有效吗？
ETA:当我从下面的答案中运行斯蒂芬提出的复制品时,我没有得到错误的答案,他说我会,我得到正确的答案.即使他说"这里的LogicalCallContext值总是"1"",我总是得到0的正确值.这可能是因为竞争条件？无论如何,我还没有在我自己的电脑上复制任何实际问题.这是我正在运行的确切代码; 它只在这里打印"真实",斯蒂芬说至少在某些时候应该打印"假".
private static string key2 = "key2";
private static int Storage2 {
get { return (int) CallContext.LogicalGetData(key2); }
set { CallContext.LogicalSetData(key2, value);}
}
private static async Task ParentAsync() {
//Storage = new Stored(0); // Set LogicalCallContext value to "0".
Storage2 = 0;
Task childTaskA = ChildAAsync();
// LogicalCallContext value here is always …我们有一个相当大的现有代码库,用于构建在ASP.NET之上的各种web服务,并且该代码大量使用访问HttpContext.Current.User(包装为Client.User),我相当确定内部使用它[ThreadStatic]来为您提供环境范围.
我目前正在研究是否有可能我们开始以形式使用更多的异步代码,async/await但我很难找到如何使用[ThreadStatic]它.[ThreadStatic]由于其大量使用,实际上不可能消除对依赖的依赖.
我的理解是,当await命中时,代码的执行在那里停止,调用立即返回,并且设置延续以在异步代码返回时继续执行.同时,原始线程可以自由地用于其他事情,例如处理另一个请求.到目前为止我对它的理解.
我无法真正找到一个确定的答案HttpContext.Current.User是,在之前和之后是否保证是相同的await.
所以基本上:
HttpContext.Current.User = new MyPrincipal();
var user = HttpContext.Current.User;
await Task.Delay(30000);
// Meanwhile, while we wait for that lots of other requests are being handled,
// possibly by this thread.
Debug.Assert(object.ReferenceEquals(HttpContext.Current.User, user));
这有Debug.Assert保证会成功吗？
如果另一个请求由与Task.Delay挂起的相同的线程处理,那么该请求将设置一个不同的HttpContext.Current.User,那么在调用continuation时以某种方式存储和恢复的先前状态是什么？
我可以想象的是,在幕后,[ThreadStatic]状态被保存为线程本身的某种字典,并且当一个线程返回到线程池后返回await该字典时,该字典在某处保持安全并且在设置回线程时它执行延续(或者在一个线程上,我不确定它是否一定是处理延续的同一个线程),可能是对屁股的鼓励和"去得到他们的男孩!",但最后部分可能只是我的想象力.
这有点准确吗？
更新:我试图将一个小试验放在一起尝试这个.到目前为止它似乎工作,并且断言没有因为数百个请求中的任何一个而失败.谁能验证测试是否有意义？