ASP.NET and ThreadStatic as part of TransactionScope's implementation

Question

I was wondering how TransactionScope class works to keep the transaction between different method calls (without the need to pass it as a parameter) and I came to this doubt. I've got two considerations about this question:

1

Looking into TransactionScope's implementation through Telerik JustDecompile, I've found that the current transaction is stored in a ThreadStatic member of the System.Transactions.ContextData class (code below).

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()
    {
    }
}

The CurrentData property is called by TransactionScope's PushScope() method, and the last one is used by most of the TransactionScope constructors.

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, I guess I've found how they do that.

2

I've read about how bad is to use ThreadStatic members to store objects within ASP.NET (http://www.hanselman.com/blog/ATaleOfTwoTechniquesTheThreadStaticAttributeAndSystemWebHttpContextCurrentItems.aspx) due the ASP.NET thread switching that might occur, so this data can be lost among the worker threads.

So, it looks like TransactionScope should not work with ASP.NET, right? But as far I have used it on my web applications, I don't remember any problem that I've run into about transaction data being lost.

My question here is "what's the TransactionScope's trick to deal with ASP.NET's thread switching?".

Did I make a superficial analysis on how TransactionScope stores its transaction objects? Or TransactionScope class wasn't made to work with ASP.NET, and I can be considered a lucky guy that never had any pain about it?

Could anyone who knows the "very deep buried secrets" of .NET explain that for me?

Thanks

Laine

+1 for very well thought out question. – Essay

Answer 1

I believe ASP.NET thread switching happens only in specific situations (involving asych IO operations) and early in the request life cycle. Typically, once the control is passed to the actual http handler (for example, Page), thread does not get switched. I believe that in most of situation, transaction scope will get initialized only after that (after page_init/load) and should not be an issue.

Here are few links that might interest you:

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

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

Proof

Yes, I guess no one will use a transaction inside an async operation, there's no reason to, so TransactionScope fits on plain vanilla ASP.NET pages. I've found another link that might be interesting lhotka.net/weblog/ASPNETThreadSwitching.aspx. Thanks, VinayC – Laine

I was about to ask this same question (and quote the same references as OP and the links you posted). I keep coming back to the rule "Don't use ThreadStatic in ASP.NET" since you can't guarantee the thread it completes on. Seems harsh, I'm surprised this hasn't been asked before. I've seen issues with thread switching on heavily loaded websites. So even if it's unlikely, it's still possible to occur, causing a pretty hard to troubleshoot problem. This link has some good Q&A, but doesn't cover the ThreadStatic issue for ASP.NET: https://mcmap.net/q/126383/-under-what-circumstances-is-an-sqlconnection-automatically-enlisted-in-an-ambient-transactionscope-transaction/137854 – Nova

@DaveTransom, although, thread switching may happen but that does not necessarily cause issue using TransactionScope - because the update database operations (that would create tranactions) will happen quite late in life cycle and unlikely to span multiple page events... For a well written code, transactions originating from UI code are going to be short-lived and encapsulated in a method within business layer (invoked by UI layer) and there is no way that thread will be switched within a method call... so I wouldn't worry about transaction scope being affected by ASP.NET thread switch – Proof