views:

95

answers:

1

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

A: 

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

MattH