作用域 DataContext 间歇性引发 ExecuteReader 错误
我们的应用程序遵循为每个线程/HttpContext 维护一个 DataContext 的方法，使用 Rick Strahl 在他的 博客，包括对Richard提到的Key的修改（使用type.AssemblyQualifiedName）。
该解决方案看起来不错（尽管在大多数情况下，不同的方法可能更好），但是在使用此解决方案时，我看到应用程序中出现间歇性错误：
ExecuteReader 需要一个开放且 可用连接。 连接的 当前状态已关闭。
我使用以下属性访问整个代码中的数据上下文，该属性是我的 DataContext 类的一部分：
/// <summary>
/// Returns the current datacontext for the thread or HttpContext, creating one if it does not exist.
/// </summary>
public static SharedDataContext Current
{
get
{
return DataContextFactory.GetScopedDataContext<SharedDataContext>();
}
}
由于间歇性，我很难确定这一点。 有谁知道我可能做错了什么，或者知道我如何调试这个问题？
请注意，这可能与未回答问题此处
Our application follows the approach of maintaining a DataContext per Thread/HttpContext, using the DataContextFactory class outlined by Rick Strahl on his blog, including the amendment to the Key mentioned by Richard (use of type.AssemblyQualifiedName).
The solution appeared sound (although in most cases a different approach may be better), however while using this I have seen intermittent errors appearing in the application:
ExecuteReader requires an open and
available Connection. The connection's
current state is closed.
I access the datacontext throughout the code using the below property, that is part of my DataContext's class:
/// <summary>
/// Returns the current datacontext for the thread or HttpContext, creating one if it does not exist.
/// </summary>
public static SharedDataContext Current
{
get
{
return DataContextFactory.GetScopedDataContext<SharedDataContext>();
}
}
Being intermittment I'm having a hard time pinning this down. Does anyone know what I might doing wrong, or have a good idea how I might be able to debug this problem?
Note this could possibly be a duplicate of the unanswered question here
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们现在使用自定义 DataContextFactory 来维护每个事务的数据上下文。 唯一的其他主要更改是对属性使用 [ThreadStatic]，而不是通过 Thread.Get/SetData 手动访问。
由于此更改，问题似乎不再出现，并且由于没有提出其他答案，我建议[ThreadStatic] 作为解决方案
We now use a custom DataContextFactory that maintains datacontexts per-transaction. The only other main change was use of [ThreadStatic] for the properties, rather than manually accessing via Thread.Get/SetData
Since this change the problem no longer seems to appear, and as no other answers have been put forward, I'm suggesting [ThreadStatic] as the solution