The help describes these settings as:

• Allow Inbound: Select this check box to allow a remote computer to flow transactions to the local computer. Typically, this option is needed on the computer that is hosting the DTC for a resource manager such as Microsoft SQL Server.
• Allow Outbound: Select this check box to allow the local computer to flow transactions to a remote computer. Typically, this option is needed on the client computer, where the transaction is initiated.

Pretty straightforward: you set Allow Outbound on the client and Allow Inbound on the SQL Server box. Except, if you are using System.Transactions with SQL Server and you promote after the first connection to the database (which means DTC gets involved), the transaction will most likely abort. Why?

If you remember my previous post on promotable transactions, in this case, the distributed transaction gets initiated on the resource manager (SQL Server) side and gets flown back to the client, which means that you actually need to set Allow Outbound on the SQL Server box and Allow Inbound on the client.

I know, it's not the most intuitive setting. Allow Inbound/Outbound were created before System.Transactions, they are still doing what they were designed to do, except that they didn't evolve with System.Transactions.

When System.Transactions was being designed, between other goals one important one was to make it easy to use. And with that, the promotion part was supposed to be as invisible as possible - things will go fast, then on demand promote to DTC and continue without any user intervention. The legacy of managing DTC network settings couldn't be avoided and thus all these details had to be explained.

But...

I can't really use transactions for long running sequences of activities. I mean, technically is possible, but the app will not scale anymore. Imagine starting the transaction today, updating databases and doing transactional work for a few days; add to that a few human interventions (when user input is required) and make it a few more days longer and only after that commit the transaction. What just happened? For those number of days, the transactional work kept all the resources that it touched in a locked state waiting for the commit (or rollback) decision. All these resources could not be used by anybody else (with various degrees of freedom depending on your isolation level) for that many days. Transactions are really meant for short lived work.

Another aspect, partial rollback - the ability to rollback some work in the case of an event, but let the rest of the work that executed so far to continue towards a possible commit. This is not possible today with how transactions are implemented: have at least one little piece of work or resource declare itself in error and the whole transaction will rollback, no exceptions allowed.

And then, maybe the most major aspect, not everything participates in a transaction. It can be a resource, it can be an action that can't rollback. Implementing resources that are transactional is not trivial, meeting all the ACID properties is hard. Or in some cases, it just doesn't make sense to make something transactional, like sending an email. What to rollback there?. Chase the internet to catch the email before it reaches ones inbox, and if it got to the inbox, tell the reader to forget it?

In all these cases, something else needs to be used in combination with short lived transactions. That means that you need to provide code that un-does/cancels/compensates the work that was already done. You need to write most of the "undo" code since the rules need to be more relaxed than with transactions. The compensation logic varies depending on the application logic at that given time. In the transactions world, the ACID requirements govern everything and there are always only two states: an initial state before transaction and a state after the transaction commits; rollback will always move the app back to the initial state. With compensation, the number of consistency states depends on the app and are defined by the app.

1.       Run “dcomcnfg”

2.       Or run: %SystemRoot%\System32\comexp.msc

3.       Or if you prefer, you can add a shortcut to %SystemRoot%\System32\comexp.msc in Control Panel

If you have UAC on and you want to do 3, first make a shortcut for %SystemRoot%\System32\comexp.msc on your Desktop and then move it to Control Panel.

One way one could achieve this without breaking the guideline is to set a flag at the end of the try block and then query it inside finally:

bool workCompleted = false;

try

{

    DoSomething();

    DoSomethingMore();

    workCompleted = true;

}

finally

{

    if (!workCompleted)

    {

        Console.WriteLine("record that the work failed");

    }

}

Fortunately, you can customize cmd by using "prompt". Do a “prompt /?” in a command window  to see all the options.

I like it simple and I use: “PROMPT=$p$_$+$g”. This gives:

C:\Windows\System32\Msdtc\Trace

> 

To persist it, set it as an environment variable.

I call it a bug. Initially I was persuaded to believe it was a feature; later I was "convinced" that it is now a matter of app compat and it can't be changed anymore.

Let’s look at the following code:

SqlConnection connection1 = new SqlConnection(connectionString);

using(TransactionScope txScope = new TransactionScope())

{

    connection1.Open();

    SqlCommand command1 = new SqlCommand(commandString1, connection1);

    command1.ExecuteNonQuery();

    SqlCommand command2 = new SqlCommand(commandString2, connection1);

    command2.ExecuteNonQuery();

    txScope.Complete();

}

…

What are your expectations from this code? I’m sure you are saying that both commands will execute with success or none will execute, for instance if command1 succeeds and command2 fails and throws, the transaction rollbacks and command1 is undone. Right?

Let’s add more data to the equation: transactions can abort at any time due to various reasons, most common one being timeouts. Let’s imagine that the transaction timeout is 30 seconds. Then, let’s imagine that command1 takes 29.(9) seconds to execute. This means that the transaction aborts immediately after that. Let’s imagine that it aborts before command2 starts executing. Now, what are the expectations here? Well, transaction aborts and then command1 is undone and everything goes back to the state before the transaction was started.

Unfortunately, by using the defaults for System.Data this is not what happens. What really happens is:

-          command1 is undone

-          command2 is executed outside the transaction

There is no typo there, command2 executes even if the transaction aborted. In other words, if one expected atomicity for the code inside TransactionScope, the code just corrupted the data due to the partial rollback.

The “Feature”

 Apparently the following code is common:

SqlConnection connection1 = new SqlConnection(connectionString);

using(TransactionScope txScope = new TransactionScope())

{

    connection1.Open();

    SqlCommand command1 = new SqlCommand(commandString1, connection1);

    command1.ExecuteNonQuery();

    SqlCommand command2 = new SqlCommand(commandString2, connection1);

    command2.ExecuteNonQuery();

    txScope.Complete();

}

SqlCommand command3 = new SqlCommand(commandString3, connection1);

command3.ExecuteNonQuery();

In other words, the “feature” allows the use of the connection in auto-commit mode after it was previously used in a transaction. The connection automatically unbinds from the transaction when the transaction completes (either abort or commit) and becomes an auto-commit non-transacted connection.

The App Compat Issue

Now that we know that the automatic unbind can lead to data corruption, changing it to not unbind automatically will make the code for command3 to fail to execute, since the connection1 is trying to run a command in a transaction that completed. Thus, if the code is indeed common, changing the behavior of the connection will indeed break existing apps.

The Solution

The solution implemented by System.Data in “Orcas” is to pass a new keyword to the connection string called “Transaction Binding” and give it the value of “Explicit Binding” to disable the auto-unbind. This will cause command2 to try to execute under the same transaction as command1, even after the abort occurred. See ConnectionString and Integration with Transactions for details.

The following thread might also be useful: https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3055387&SiteID=1

Hopefully, the default behavior will change to explicit unbind in the future releases (non-SP) of .Net Framework.

OK, so how about this code:

using(TransactionScope ts = new TransactionScope(TransactionScopeOption.RequiresNew)) {

    // do transactional work

    ts.Complete();

    throw new Exception();

}

What happens to the transaction after executing this code? Take a guess. If we follow the doc, the transaction roll backs, right? Well, the transaction actually commits – try it out!

Let’s see what happens by “unpacking” the using statement:

TransactionScope ts = new TransactionScope(TransactionScopeOption.RequiresNew);

try {

    // do transactional work

    ts.Complete();

    throw new Exception();

}

finally {

    ts.Dispose();

}

In the Dispose of TransactionScope something similar to the following pseudo-code happens:

       if Complete was called {

              Transaction.Commit();

}

else {

       Transaction.Rollback();

}
 

The limitation really comes from the fact that at Dispose time in finally, the using construct doesn’t offer any information about completion of its body with exception or not. That is why the Transaction.Complete was invented and that is why the documentation for Complete says: “It is very good practice to put the call as the last statement in the using block.” Complete was invented to detect exceptions, i.e. if an exception occurs, Complete will not get called – but this work only if one follows the guideline to put Complete as the last statement. Doing any work after Complete was called is asking for trouble and possible data corruption. 

If you want to be on the safe side, use my transacted construct which doesn’t have these issues. It follows a simple rule: if an exception is thrown, the transaction aborts, otherwise it commits.

This was by far the most requested feature for the System.Transactions/System.Data/SQL Server combination.

There is no more the need to write workarounds like ConnectionScope to avoid promotions.

Now I can write as many Open/Close, Open/Close as I need to, without worrying about promotion:

transacted(()=>
{
   using (SqlConnection connection1 = new SqlConnection(connectionString))
   {
      Connection1.Open();

      SqlCommand command1 = new SqlCommand(commandString1, connection1);
      command1.ExecuteNonQuery();

      SqlCommand command2 = new SqlCommand(commandString2, connection1);
      command2.ExecuteNonQuery();

      connection1.Close();
   }

   ...

   using (SqlConnection connection2 = new SqlConnection(connectionString))
   {
      Connection2.Open();

      SqlCommand command1 = new SqlCommand(commandString1, connection2);
      command1.ExecuteNonQuery();

      SqlCommand command2 = new SqlCommand(commandString2, connection2);
      command2.ExecuteNonQuery();

      connection2.Close();
   }
});

More details on the updates at the ADO.Net team blog.