Transactions . . .

Cheese Pairing for this Post: 1-year-old, Cave-Aged Gruyere
[this is a great one that you can really enjoy every once in a while under the right circumstances]

So, this week a user story was assigned to me that said something like, "Make sure that we don't save and of the Order data if we can't save ALL the Order data." Immediately, I thought, "Sounds like time to add some transactional support to our (custom) repositories." So there I am adding some tests to the repositories solution that assert that I have some infrastructure in place to track all of the database connections, etc, when one of my co-workers says, "Why don't you just use TransactionScope?" This was new to me, so here is what I learned:

TransactionScope is a class built on the Microsoft Distributed Transaction Coordinator. It basically wraps up all that hard work of tracking and committing or rolling back transactions across multiple connections into an easy to use interface, like so:

void MethodWithTransaction()
{
    using(TransactionScope scope = new TransactionScope())
    {
        /* Perform transactional work here */
        scope.Complete();
    }
}

That's it. If you get to scope.Complete(), the transaction(s) commit. If you don't get there, the whole thing rolls back when the TransactionScope is disposed.

Ok, you knew that wasn't all there is to it right? You have to configure your SQL Servers to run the DTC components. I didn't do this as our OPS team already had it done. I did have to do some config on my machine though. Here are the steps:

Run dcomcnfg:

Right-click My Computer and open up the properties. Go to the MSDTC tab:

Click the Security Configuration button:


Those are the setting that work for me. I also had trouble with the firewall we used here at work, but our networking guys were able to resolve that as soon as I mentioned DTC.

In the (likely) event that you need more info, try these links:

Troubleshooting Problems with MSDTC

How To Use DTCTester Tool

Good Luck!