ASP.NET und ThreadStatic als Teil der Implementierung von TransactionScope

Question

Ich habe mich gefragt, wie die TransactionScope-Klasse funktioniert, um die Transaktion zwischen verschiedenen Methodenaufrufen zu halten (ohne die Notwendigkeit, sie als Parameter zu übergeben), und ich kam zu diesem Zweifel. Ich habe zwei Überlegungen zu dieser Frage:

1

Bei der Untersuchung der TransactionScope-Implementierung durch Telerik JustDecompile habe ich festgestellt, dass die aktuelle Transaktion in einem ThreadStatic-Mitglied der Klasse System.Transactions.ContextData (Code unten) gespeichert wird.

internal class ContextData
{
    internal TransactionScope CurrentScope;

    internal Transaction CurrentTransaction;

    internal DefaultComContextState DefaultComContextState;

    [ThreadStatic]
    private static ContextData staticData;

    internal WeakReference WeakDefaultComContext;

    internal static ContextData CurrentData
    {
        get
        {
            ContextData contextDatum = ContextData.staticData;
            if (contextDatum == null)
            {
                contextDatum = new ContextData();
                ContextData.staticData = contextDatum;
            }
            return contextDatum;
        }
    }

    public ContextData()
    {
    }
}

Die CurrentData-Eigenschaft wird von der PushScope()-Methode von TransactionScope aufgerufen, und die letzte Eigenschaft wird von den meisten TransactionScope-Konstruktoren verwendet.

private void PushScope()
{
    if (!this.interopModeSpecified)
    {
        this.interopOption = Transaction.InteropMode(this.savedCurrentScope);
    }
    this.SetCurrent(this.expectedCurrent);
    this.threadContextData.CurrentScope = this;
}

public TransactionScope(TransactionScopeOption scopeOption)
{
    // ...
    this.PushScope();
    // ...
}

Ok, ich glaube, ich habe herausgefunden, wie sie das machen.

2

Ich habe gelesen, wie schlecht es ist, ThreadStatic-Mitglieder zum Speichern von Objekten in ASP.NET (http://www.hanselman.com/blog/ATaleOfTwoTechniquesTheThreadStaticAttributeAndSystemWebHttpContextCurrentItems.aspx) aufgrund der ASP.NET-Thread-Switching, die auftreten können, zu verwenden, so dass diese Daten zwischen den Arbeiter-Threads verloren gehen können.

Es sieht also so aus, als sollte TransactionScope nicht mit ASP.NET funktionieren, richtig? Aber so weit ich es auf meine Web-Anwendungen verwendet haben, ich erinnere mich nicht an ein Problem, das ich in über Transaktionsdaten verloren gehen laufen.

Meine Frage hier ist "was ist die TransactionScope's Trick, um mit ASP.NET's Thread-Switching umgehen?".

Habe ich eine oberflächliche Analyse darüber gemacht, wie TransactionScope seine Transaktionsobjekte speichert? Oder wurde die TransactionScope-Klasse nicht für die Arbeit mit ASP.NET entwickelt und ich kann mich glücklich schätzen, dass ich nie Probleme damit hatte?

Könnte mir das jemand erklären, der die "sehr tief verborgenen Geheimnisse" von .NET kennt?

Danke

Answer 1

Ich glaube, ASP.NET-Thread-Umschaltung geschieht nur in bestimmten Situationen (mit asych IO-Operationen) und früh im Lebenszyklus der Anforderung. In der Regel, sobald die Kontrolle an die eigentliche http-Handler (z. B. Seite) übergeben wird, Thread wird nicht umgeschaltet. Ich glaube, dass in den meisten Situationen der Transaktionsbereich erst danach initialisiert wird (nach page_init/load) und kein Problem darstellen sollte.

Hier sind einige Links, die Sie interessieren könnten:

http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html

http://piers7.blogspot.com/2005/12/log4net-context-problems-with-aspnet.html