Scoped DataContext stellt zeitweise den Executereader -Fehler auf

Question

Unsere Anwendung folgt dem Ansatz, einen DataContext pro Thread/httpcontext bei der Verwaltung der von Rick Strahl beschriebenen DataContextFactory -Klasse auf seinem Blog, einschließlich der Änderung des von Richard genannten Schlüssels (Verwendung von Typ.SemblyQualifiedName).

Die Lösung erschien ein Geräusch (obwohl in den meisten Fällen ein anderer Ansatz besser sein kann), obwohl ich in der Anwendung intermittierende Fehler gesehen habe:

Executereader benötigt eine offene und verfügbare Verbindung. Der aktuelle Zustand der Verbindung ist geschlossen.

Ich greife über die folgende Eigenschaft auf den DataContext im gesamten Code zu, der Teil der Klasse meines DataContext ist:

/// <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>();
    }
}

Wenn ich Intermittment bin, fällt es mir schwer, das festzuhalten. Weiß jemand, was ich falsch mache oder eine gute Idee habe, wie ich dieses Problem möglicherweise debuggen kann?

---

Beachten Sie, dass dies möglicherweise ein Duplikat der sein könnte unbeantwortet Frage hier

Answer 1

Wir verwenden jetzt eine benutzerdefinierte DataContextFactory, die DataContexts pro Transaktion verwaltet. Die einzige andere Hauptänderung war die Verwendung von [Threadstatic] für die Eigenschaften, anstatt manuell über Thread.get/setData manuell zugänglich zu machen.

Da diese Änderung das Problem nicht mehr zu erscheint und wie keine anderen Antworten vorgelegt wurden, schlage ich [Threadstatic] als Lösung vor