Angel Saenz-Badillos : Distributed Transactions

ADO.NET 2.0 and System.Transactions, downlevel functions and nested scopes

angelsb — Sat, 12 Feb 2005 05:59:00 GMT

As with most of my blog posts this started as a customer question, the core of the problem was that he was not sure how he was expected to use TransactionScopes in methods that call other methods or "downlevel" functions as he named them.

There are two important concepts to keep in mind.

1) downlevel functions should not know or care about what happens on the functions that call them. Don't pass TransactionScope as properties, don't assume that there is an existing transaction, etc.

2)You can nest TransactionScopes (with the default TransactionScopeOption, "Required") or isolate downlevel functions from outer TransactionScopes (with the optional Suppress and RequiresNew TransactionScopeOption(s) )

Here is some pseudo code for a small stress app I wrote that shows some of this off:

InsertMoneyIntoAccount() //doesn’t use transactions

RemoveMoneyFromAccount() //doesn’t use transactions

TransferMoney() //creates TransactionScope then calls RemoveMoney and InsertMoney

TransferMoneyWithExtraCharges //creates TransactionScope, calls TransferMoney and RemoveMoneyFromAccount

// the TransactionScope in TransferMoney will be nested inside the outer Scope.

A more advanced (and to my way of thinking less recommended) concept is nesting Scopes where you do not want the behavior in the downlevel functions to affect outer scopes, you can do this by using the TransactionScopeOption.RequiresNew and Suppress enum values.

TransferVerifyAndTransfer() //creates a TransactionScope, calls Transfer, uses retry logic to call VerifyTransfer multiple times and once the transfer is verified calls Transfer again. The main problem here is that we don’t want a fatal exception in VerifyTransfer to roll back the transaction since we are building in logic to retry on exception.

VerifyTransfer() //creates a TransactionScope with TransactionScopeOption.Suppress, this guarantees that it will not affect the scopes in uplevel functions.

//It is important to realize that some exceptions even when handled can affect the transaction. In the example below if we don’t use the Suppress option for B’s TransactionScope then the ExecuteNonQuery (level 20 exception) will cause A’s outer TransactionScope to be rolled back.

public void A(){

using (TransactionScope transactionscope1 = new TransactionScope()){

this.B( );

transactionscope1.Complete()

}

public void B(){

//always create a TransactionScope with the “using” language construct.

using (TransactionScope transactionscope1 = new TransactionScope(TransactionScopeOption.Suppress)){

//always create a connection with the “using” language construct.

using (SqlConnection sqlconnection1 = new SqlConnection(connectionstring)){

sqlconnection1.Open();

SqlCommand sqlcommand1 = sqlconnection1.CreateCommand();

sqlcommand1.CommandText = "raiserror ('my error', 20, 20) with log";

try {

sqlcommand1.ExecuteNonQuery();

}

catch(Exception e){

Console.WriteLine(e.Message);

}

transactionscope1.Complete();

} //Here sqlconnection1 is _guaranteed_ to be disposed. I think it is a good idea to do this before the scope is disposed.

}

Rambling out: This post is provided "AS IS" and confers no rights.

ado.net 2.0 changes in latest community drop.

angelsb — Tue, 16 Nov 2004 23:17:00 GMT

Well, it has been a long time since my last blog and it is going to be a while before I get going again. Whenever this happens you can count on me being either insanely behind or on vacation.

I am happy to report that the insanely behind part is over. The ado.net team has hit ZBB on time and on schedule (I have the WE ROCK mail to prove it :). I am really looking forward to getting some feedback on the latest community drop. There have been some changes… some minor some not so minor. A lot of improvements, bug fixes and sweat lots of sweat. Now it is time to see how it holds out in the real world.

The reason I am not going to be able to pick up blogging where I left off is that next week I am off on vacation. I am thinking it is time to go to a warm country and pass out by a swimming pool.

Important (to me *grin*) changes:

1)The System.Transactions namespace has received a fairly significant makeover.

The System.Transactions team has been busy, some of their changes affect our components so I am writing what I know about them. This is definitelly not an official source, I am only commenting on the changes in the latest comunity drop.

Transaction.Create has been removed, we now have a CommittableTransaction class to represent a lightweight transaction.

CommittableTransaction committabletransaction1 = new CommittableTransaction();

You can still specify timeout (default 1 minute) and isolation level by using the newly renamed TransactionOptions. This now supports Snapshot isolation level.

TransactionOptions transactionoptions1 = new TransactionOptions();

transactionoptions1.IsolationLevel = IsolationLevel.ReadCommitted

CommittableTransaction committabletransaction2 = new CommittableTransaction(transactionoptions1);

Checking the GUID of the distributed transaction will no longer promote the transaction to return a valid value, we now support returning null for lightweight transactions.

We can no longer change the default serialization level of a distributed transaction in the config file. Isolation level is a development time concern, not a runtime issue.

The TransactionScope now has only 8 constructors (down from something like 14?). Only Required, RequiresNew and Supress TransactionScopeOptions are now available (making things much less confusing I think)

The TransactionScope Consistent property had a fundamental design problem, it can be set multiple times making it confusing to use, setting it to true and false multiple times inside of the same scope is considered bad. This has been replaced with a method Complete(). This method does not actually complete the distributed transaction, commit will still happen on TransactionScope dispose. The main difference is that after calling this method you can no longer use the distributed transaction.

2) We are trying to get OleDb and Odbc managed connections to auto enlist in System.Transactions transactions.

Currently only SqlClient and the Oracle managed provider support this since they are managed providers instead of wrappers, we are trying to bring this functionality to the managed wrappers (it is hard, so no promises)

3)The ExecuteRow method is now on the verge of being removed.

I hate duplicating the same work with a different api and code path, it always always results in trouble. Removing this (to my eyes)

unnecessary api would be a big win.

Rambling out,

This post is provided AS IS and confers no rights. The information posted applies only to the latest community drop of the Whidbey framework, NOT to the beta1. Information posted in this post is DEFINITELLY not final.

ADO.NET 2.0 The connection pool and distributed transactions

angelsb — Thu, 07 Oct 2004 18:37:00 GMT

I am a big fan of pop quiz style blogs like the ones you can find here: http://blogs.msdn.com/brada/ .

I am not really sure that there are enough people looking at this blog to make this fun but I am going to give it a try. I will incorporate the answer in the blog at a latter time for reference.

Pop quiz,

Connection pooling can get pretty confusing when distributed transactions are in use, in the following code I am setting the following connection string keywords:

Max Pool Size=1

Enlist =false

using System.Transactions.Ltm;

using System.Transactions;

using System;

using System.Data.SqlClient;

namespace DataViewer.Repro {

public class Repro {

public static int Main(string[] args) {

try{

TransactionScope transactionscope1 = new TransactionScope();

ITransaction itransaction1 = Transaction.Current; // LightweightTransaction

SqlConnection sqlconnection1 = new SqlConnection(ConnectionString+";Max Pool Size=1;Enlist=false");

sqlconnection1.Open();

sqlconnection1.EnlistTransaction((ITransaction)itransaction1);

sqlconnection1.Close();

//System.Threading.Thread.Sleep(61*1000); //ß Line 1

sqlconnection1.Open(); //ß What is the behavior here?

}catch(Exception ex){Console.WriteLine(ex.Message.ToString());}

return 1;

}

Well, time to aknowledge that this is not going to work, let me just explain how this works:

“What is the behavior here?” sqlconnection1.Open will work or throw an exception given the information specified below:

1) With the code as shown. (no waiting 61 seconds)

The connection will fail to open. On connection close we will realize that the connection is currently participating in a distributed transaction and we will not place it back into the regular pool. This transacted connection will be placed in a sub-pool and will only be taken out when the transaction completes (we get a notification) or if you open another connection with the same connection string and enlisted to the same distributed transaction (impossible in this case due to Enlist=false). When you call Open again we compare the size of the pool (including the subpool) with the Max Pool Size of 1 and fail to Open with a "timeout exception" The timeout period elapsed prior to obtaining a connection from the pool.

2) If you uncomment “Line 1” so that you wait 61 seconds before calling Open.

The connection will open. As above we will place the connection on the transacted subpool, the difference here is that the default timeout of

a distributed transaction is 1 minute. When the minute is up the transaction will roll back and we will get a notification saying that it is completed.

We will then take the connection out of the subpool and place it back in the regular pool. When we call Open a second time there will be a free

connection waiting in the pool.

Setting the IsolationLevel using the System.Transactions TransactionScope.

angelsb — Tue, 27 Jul 2004 23:17:00 GMT

Traditionally distributed transactions have always run in Serializable isolation level, the safest but most expensive transaction isolation level where everything that we look at is locked from the moment we modify something and until the distributed transaction completes. This is very expensive and most of the time it is not necessary, fortunately we are no longer required to point users to this handy KB article http://support.microsoft.com/default.aspx?scid=kb;EN-US;215520#appliesto , we now support other isolation levels.

Here is an example of setting the Isolation level using the awesome TransactionScope (the default is still Serializable)

using System.Transactions;
using System.Data.SqlClient;
using System;
namespace DataViewer.Repro {

public class Repro {

        public static int Main(string[] args) {
            TransactionOptions transactionoptions1 = new TransactionOptions();
            transactionoptions1.IsolationLevel = IsolationLevel.ReadCommitted;
            using (TransactionScope transactionscope1 = new TransactionScope(TransactionScopeOption.Required, transactionoptions1)){
                ITransaction mycurrenttx = Transaction.Current;
                Console.WriteLine(mycurrenttx.Identifier);
                Console.WriteLine(mycurrenttx.ToString());
                Console.WriteLine(mycurrenttx.IsolationLevel);
                Console.WriteLine(mycurrenttx.Status);
                using (SqlConnection sqlconnection1 = new SqlConnection("Server=.\\SQLEXPRESS ;Integrated security=sspi")) {
                          sqlconnection1.Open(); //this autoenlists in the transaction scope.
                          //do your work here.
                }
            }
            return 1;
        }
    }
}

Here I am using SqlExpress, make sure to start MSDTC (“net start msdtc” from the command line) since this service is not enabled by default.

Rambling out, Standard Disclaimer: This post is provided “AS IS” and confers no rights.

ADO.NET Distributed transactions, loose ends.

angelsb — Thu, 15 Jul 2004 14:40:00 GMT

There is still a lot of information related to using ADO.NET with System.Transactions Distributed Transactions, but in the interest of keeping the blog moving I am going to roll up most of the issues into this final post. Feel free to post questions if anything does not make too much sense.

Random ramblings:

The first connection _may_ be special. To make usage of promotable transactions transparent we have modified the api to artificially hide this.

If the first connection that we enlist into a LightweightTransaction is to a Sql Server 2005 we create a promotable transaction that is really nothing but a local transaction. For us to be able to promote this at a later time we need to make sure that we keep a reference. We have essentially hijacked this connection to talk to the server about the distributed transaction and bad things would happen if we tried to unenlist this connection. We used to be able to enlist and unenlist connections from distributed transactions at will (not that I would recommend this), and we could still do this if we wished for any connection other than these “special” connections. To avoid confusion and simplify the model we have decided to dis-allow unenlistment for all connections when using System.Transactions distributed transactions. Let me know if this is blocking an important scenario that we have not been able to think about.

Distributed transactions and threading:

The first question I got on TransactionScope was that since this sets a static Transaction.Current property would we run into trouble when using multiple threads? No, there is (or rather should not be) any problems with this scenario. Transaction.Current lives in thread local storage (TLS) so it is scoped per thread. If you want to enlist all the threads in the same distributed transaction it is slightly more complicated, the important concept to remember here is that commit may not be thread safe. The solution is to rely on the Clone command of the transaction, a cloned transaction can be rolled back, but it cannot commit. Pass a clone of your main transaction to each thread and manually enlist.

The TransactionOptions object for System.Transaction.Create(TransactionOptions)

I am not a big fan of this name, to me it seems like I am going to be able to set “traditional” transaction options like required, requiresnew etc. Instead this object allows you to set timeout and isolation level for a transaction. I have to point out that setting the isolation level on the transaction does not guarantee that your transaction will run in this mode, it is more of a suggestion to the resource manager.

TransactionOptions transactionoptions1 = new TransactionOptions();

transactionoptions1.IsolationLevel = IsolationLevel.ReadCommitted;

ICommittableTransaction icommittabletransaction1 = Transaction.Create(transactionoptions1); // LightweightCommittableTransaction

Standard Disclaimer, this post is provided “AS IS” and confers no rights.

Rambling out

Whidbey ADO.NET Promotable Transactions with System.Transactions & Yukon

angelsb — Tue, 13 Jul 2004 00:45:00 GMT

There is a special partnership between System.Transactions and Sql Server 2005, and no, it is not the fact that we begged the Enterprise Services team to ship this feature on whidbey and it is not (only) the fact that this is the only way to get distributed transactions to work inproc in Yukon (will talk about that in another blog). What makes the relationship special is that Sql Server 2005 understand Lightweight Transactions, uses Lightweight Transactions whenever possible, optimizes the use of Lightweight Transactions and does all this as transparently as we have been able to make it.

So what is a LightweightCommittableTransaction? The long answer is that it is what you get when you call System.Transactions.Transaction.Create() with the default DefaultTransactionManager set to LightweightTransactionManager. The short answer is that it is an in memory transaction that can be promoted to a full dtc. Neither of these definitions may be what you are looking for, so I have put this one together all by my lonesome:

Question>What is a LightweightCommittableTransaction as far as ado.net is concerned?

Angel>A transaction that looks like a distributed transaction, smells like a distributed transaction and tastes like a distributed transaction. Oh yeah, it can be a lot faster btw.

Let’s see this in action, bring up the trusty Component Services Transaction Statistics

(start->control panel->administrative tools->Component Services->Component Services->Computers->MyComputer->Distributed Transaction Coordinator -> Transaction Statistics)

This tool tracks distributed transactions as they happen, let’s give it a whirl. You should already be familiar with the code below from a previous blog, I have modified it slightly to show off a transaction being delegated, then promoted.

using System;

using System.Data.SqlClient;

using System.Transactions;

public class Repro {

public static int Main(string[] args) {

using(TransactionScope transactionscope1 = new TransactionScope()) {

//Delegation only works against Sql Server 2005, for this example to work this connection must point to one.

using (SqlConnection sqlconnection1 = new SqlConnection(SqlServer2005ConnectionString)) {

sqlconnection1.Open(); //The connection enlists, but does not promote

//do your work 1 here.

}

Console.WriteLine("Check your Transaction Statistics Active transactions here, then press enter");

Console.ReadLine();

//This connection can point to any Backend that supports DTC. Sql Server 7, 2000, 2005 or Oracle

using (SqlConnection sqlconnection2 = new SqlConnection(ConnectionString2)) {

sqlconnection2.Open(); //The connection enlists, automatically promotes the transaction.

//do your work 2 here.

}

Console.WriteLine("Check your Transaction Statistics Active transactions here, then press enter");

Console.ReadLine();

// Set the scope to commit by setting the following property:

transactionscope1.Consistent = true;

}// when the TransactionScope is disposed it will check the Consistent property. If this is true the DTC will commit, if it is false it will roll back.

return 1;

}

What just happened? Well if you run this code to the first ReadLine you will see that there are no Transactions Active showing! We have created a TransactionScope, we have opened a connection that enlists into this scope, but since we are connected to Sql Server 2005 and we don’t have the need for a full distributed transaction we have Delegated the promotion of the transaction. We have opened a local transaction with all of the performance implications that this implies, and all of the “work 1” will be done under this local transaction. After the first ReadLine we open a connection to a second server which could or could not be the exact same server that we are connecting to with sqlconnection1. On sqlconnection2.Open the Lightweight Transaction realizes that it no longer can remain “light” and converts into a full COM+ distributed transaction, at that point we will finally be able to see an Active transaction show in our Component Services tool.

Wait, wait! What about the local transaction that we are using against the first server? Nothing to worry about, we will promote the local transaction into the full distributed transaction, you will not even know that the first transaction was only local. Most of the time the MSDTC of the first server will own the distributed transaction from this point on. Why not all of the time? Well this depends on a heuristics feature that the Enterprise Service is working on, I really don’t know what the current state of this feature is, but the basic idea is that they will keep track of when a transaction is getting promoted and be able to promote at the optimal time to improve performance.

Bottom line, we want this feature to be completely transparent to the end user from the ado.net point of view. It should not matter whether delegation happens or not you should always get the same robust Distributed Transaction behavior you know and love, it’s just that sometimes, it will work a lot faster.

Standard Disclaimer, All information posted here is “AS IS” and confers no rights. This is not a finished article and it is very likely going to contain some errors.

Rambling out.

Whidbey ado.net 2.0 Manually enlisting into System.Transaction distributed transaction.

angelsb — Mon, 12 Jul 2004 16:20:00 GMT

I have gone over the TransactionScope in fair detail, it is now time to look at manual enlistment, the second way to use System.Transactions Distributed Transactions with ADO.NET. Unlike the TransactionScope example wich was complete and bullet proof this is neither. Here we still need to specify the logic for rolling back the transaction and we run the risk of leaking the transaction. I have not attempted to do this because quite frankly I am not certain that I would get it right in a generic enough way that can be copied pasted into your project.

ICommittableTransaction icommittabletransaction1 = Transaction.Create(); // LightweightCommittableTransaction

using (SqlConnection sqlconnection1 = new SqlConnection(ConnectionString)){

sqlconnection1.Open();

sqlconnection1.EnlistTransaction((ITransaction)icommittabletransaction1);

//Do your work here

}

icommittabletransaction1.Commit();

Again, let's go line by line.

ICommittableTransaction icommittabletransaction1 = Transaction.Create();

Transaction is the System.Transactions.Transaction, Create is a Static method that returns an ICommittableTransaction. It has overloads for a TransactionOptions object (this is not necessarily what you may expect by the name, another blog on this later) and for timeout (default 1minute). The Create() method is a lot more complicated than it looks, under the covers it relies on the DefaultTransactionManager to create the type of transaction that you are currently working on. By default the default transaction manager is set to be of type LightweightTransactionManager so we get a LightweightCommittableTransaction back in this case. Lightweight transactions are the true power behind the System.Transaction class, they are in memory transactions with all of the speed benefits that that entails and they can be promoted to distributed transactions with all their power. A truly astonishing feature for the Enterprise Services team. We have modified Sql Server 2005 to be able to work with these lightweight transactions… up to a point, another blog on this later.

Important: on Transaction.Create the Transaction.Current property is not set, connections will _not_ automatically enlist into this transaction. There is nothing stopping you from manually setting the static property Transaction.Current to a transaction that you have started with Create however: ex: Transaction.Current = (ITransaction) icommittabletransaction1;

sqlconnection1.Open();

No magic, but worth repeating. The connection opens but does not automatically enlist into the LightweightCommittableTransaction.

sqlconnection1.EnlistTransaction((ITransaction)icommittabletransaction1);

Manually enlisting the connection into the LightweightCommittableTransaction. Manually enlisting connections into distributed transactions was a new feature with the v1.1 version of the framework, to manually enlist into an Enterprise Services DTC we added the EnlistDistributedTransaction method in the connection. I bring this up because our first stumbling block in integrating System.Transactions was that we could not overload this method to handle both ContextUtil and System.Transactions. I believe (but don't quote me on that) that overloading was not possible due to language issues with vb.net, but most importantly, there are some minor behavior differences that come up due to transaction delegation. The most important of these differences is that _you cannot unenlist_ the connection. That is right, once you manually enlist into a distributed transaction you can’t enlist the connection into the null transaction or into a different transaction like you could (but I hope you did not do) with Enterprise Service transactions. There is a reason for this, I will blog on this later. In a nutshell the first connection that you open _can_ be special due to delegation and transaction promotion.

icommittabletransaction1.Commit();

Not much to say here, we don’t have the strange commit or rollback on dispose based on a property that works so well for the TransactionScope, you need to Commit or Rollback manually.

I believe I have promised at least three more blogs on this blog alone, I imagine I am going to be talking about this feature for a while longer. I am trying to convince Sushil Chordia to blog on Notifications (mostly so I don’t have to J ) but there are a lot of other areas that I really want to talk about.

Standard Disclaimer: This post is provided “AS IS” and confers no rights, there are almost certainly going to be errors in this post.

Rambling out,

Angel

More setup information, straight from the source

angelsb — Mon, 12 Jul 2004 14:28:00 GMT

Florin Lazar was the person that first introduced me to System.Transactions, he has a great weblog here:

http://blogs.msdn.com/florinlazar/

That is full of information on how to set up your computer to use distributed transactions and really great links to what you can expect from System.Transactions in the future.

Whidbey ADO.NET 2.0 System.Transactions Distributed Transactions. TransactionScope

angelsb — Wed, 07 Jul 2004 15:47:00 GMT

Let’s take a look at how the new System.Transactions Distributed Transactions work with ADO.NET 2.0. I am going to start with the best and easiest way to use distributed transactions in managed code, the TransactionScope. The following code is (or should be) bullet proof, without even realizing it you have bypassed most of the hidden problems that you can run into.

using(TransactionScope transactionscope1 = new TransactionScope()) {

using (SqlConnection sqlconnection1 = new SqlConnection(ConnectionString)) {

sqlconnection1.Open(); //this autoenlists in the transaction scope.

//do your work here.

}//SqlConnection using statement completed

// Set the scope to commit by setting the following property:

transactionscope1.Consistent = true;

}// when the TransactionScope is disposed it will check the Consistent property. If this is true the DTC will commit, if it is false it will roll back.

Let’s analize this line by line:

using(TransactionScope

This is CRUCIAL, relying on the using construct to create your scope makes everything so simple that I can’t imagine not doing it. You can easily see your scope and what it is affecting, that is nice. The truly important reason for the using statement though is that you _need_ to guarantee that this scope is going to be Disposed. The way the transaction scope is designed it will Commit or Rollback on TransactionScope.Dispose, leaving this to the GC can be tremendously expensive since System.Transactions Distributed Transactions have the same 1 minute timeout default. Locking multiple databases for up to a minute is going to kill scalability in your application. I say kill but I really mean devastate, destroy, shatter and make you pull your hair out… you get the idea. No, it is not enough to call TransactionScope.Dispose manually in your code unless you place it in the finally block of a try finally block and all of your work is done in the try. If an exception in your code throws out of your code before Dispose is called you are going to hate this feature.

new TransactionScope()

It is interesting to see what the overloads are for the TransactionScope constructor… WOA 14 overloads. Man I am glad I don’t own testing this object J. I am not even going to try going through this list I am just going to note that the default no parameter constructor is equivalent to the TransactionScope(TransactionScopeOption.Required). For those of you familiar with distributed transaction terminology, yes, this means that the Scope requires a transaction. Our scope will run in the scope of an existing distributed transaction if one exists, if no transaction exists the Scope will start one. Yes, this means that you can nest TransactionScopes! Most (but not all) of the other TransactionScopeOptions will be familiar to people familiar with Distributed Transactions, I will revisit this at a later time in this blog. Take a look at the overload that takes in a TransactionOption, this allows you to set an IsolationLevel.

using (SqlConnection

The exact same comment as for using TransactionScope, nothing but a “using” or a try finally guarantees the SqlConnection closes. You really don’t want your connection to leak here.

sqlconnection1.Open()

Magic, we call connection open and our connection automatically enlists on the scope, what is going on here? Take a look at the System.Transactions.Transaction.Current static property, this is set to null by default, but check it after you create a new TransactionScope and you will see that it gets set to a LightweightTransaction. Whenever we open a new SqlClient or Oracle Client connection with Enlist=true (the default) on the connection string we will check this static Transaction.Current property, if this property is set our Connection will automatically enlist into this LightweightTransaction. If you are connecting to Sql Server 2005 the transaction will continue being lightweight after Open, connecting to any other backend (Sql Server 2000, Sql Server 7, Oracle) will result in immediate promotion to a full Distributed Transaction. You can track these transactions in the awesome TransactionStatistics view of the Admin->Component Services utility.

//do your work here.

Pretty self explanatory, the connection is open, the scope is running, you are using expensive resources. I would recommend doing only Updates, Inserts and Deletes here, doing selects (which may be unfortunately necessary) will lock the database(s) unnecessarily. Any non database work should be done outside of the scope. By default System.Transactions have a 1 minute timeout, you can play with the TransactionScope constructor overloads to change this.

Important: What happens if an exception happens here? Well unless you handle it yourself your code will throw. First the SqlConnection Dispose will happen since this is guaranteed by the using (SqlConnection, then TransactionScope.Dispose will be called since this is guaranteed by the using(Transactionscope. On TransactionScope Dispose we check the Consistent property (false by default), in this case it is set to false (the throw happens in //do your work here, and Consistent=true never gets called) and the Rollback is _guaranteed_. It’s all good <g>

}//SqlConnection using statement completed

This guarantees that SqlConnection.Dispose will be called here, it is important to note that this is being done _before_ we commit or rollback the TransactionScope. This is not _necesary_, but it is highly recommended. You sidestep a lot of problems by closing the connection here and letting us baby sit it for you until the Distributed Transaction completes. We take the connection and place it in a special subpool for connections currently enlisted in a distributed transaction, we listen to the distributed transaction completed event and then return the connection to the available connection pool. If you don’t close the connection you cannot reuse it until the distributed transaction has completed (this is _not_ right after TransactionScope.Dispose!), you could listen to the Distributed Transaction completed event but then you get into a race condition with our connection clean up code that gets triggered on this event, this could get ugly.

transactionscope1.Consistent = true;

This tells the TransactionScope to Commit on TransactionScope.Dispose.

}//when the TransactionScope is disposed it will check the Consistent property. If this is true the DTC will commit, if it is false it will roll back.

Nothing new to add here. We are done.

Rambling out

Standard Disclaimer. This post is provided “AS IS” and confers no rights. Anything posted here is strictly my opinion. There are almost certainly going to be a number of errors on this post.

Whidbey ADO.NET System.Transactions Distributed Transactions

angelsb — Tue, 06 Jul 2004 15:39:00 GMT

This is imo one of the best new features for ADO.NET imo and I was glad to get some feedback that expressed interest. I will blog on this feature for the rest of the week, here is how to get started.

The hardest thing about this feature is without a doubt the OS setup required. Most user problems are going to come from this. You need to make sure that both your client and your Server are set up to allow distributed transactions.

To give you an idea:

Windows XP:

You need to install Q828758, contact PSS directly for this hotfix. I believe but have not been able to confirm that this fix is included in XP Service Pack 2 RC2.

Windows XP Service Pack2 RC2

With SP2 Network DTC Access is disabled by default. To enable Network DTC Access go to Start->Control Panel->Component Services. Navigate to Component Services->Computers->My Computer and right click on My Computer->Properties. In the MSDTC tab->Security Configuration enable Network DTC Access, Allow remote clients, Allow inbound, Enable Transaction Internet Protocol, Enable Transaction Internet Protocol and Enable XA Transactions. You probably don’t need to turn everything on, I just don’t know enough to know which ones are not needed.

Windows 2003

Distributed Transactions are not installed by default; you need to go to Add remove programs->Add remove Windows Components-> Application Server and install both COM+ and DTC support.

Windows 2000

You need to install service pack 4.

Once you have the setup out of the way this feature is as simple as:

using System;

using System.Data.SqlClient;

using System.Transactions;

namespace DataViewer.Repro {

public class Repro {

public static int Main(string[] args) {

using(TransactionScope transactionscope1 = new TransactionScope()) {

using (SqlConnection sqlconnection1 = new SqlConnection(ConnectionString)) {

sqlconnection1.Open(); //this autoenlists in the transaction scope.

//do your work here.

}

// Set the scope to commit by setting the following property:

transactionscope1.Consistent = true;

}// when the TransactionScope is disposed it will check the Consistent property. If this is true the DTC will commit, if it is false it will roll back.

return 1;

}

There is no need to derive from anything, no magic properties, no com interaction so no strong name or regsvcs no problems with the gac… it just works. Every SqlConnection or OracleConnection that I open inside of the “using TransactionScope” statement will automatically enlist in the transactionscope1 and commit or rollback as one.

A really cool feature here is that when our ConnectionString points to a Sql Server 2005 we will use Delegated Transactions whenever possible. What this means is that on SqlConnection Open we will not create a Distributed Transaction, instead we create a local promotable transaction, it will remain a local transaction with the performance implications that this entails until such a time in which we require more. As soon as you try to open a second connection the delegated transaction will be promoted to a full DTC. I am not certain that Distributed Transactions work with the Express version of Sql Server 2005.

Scenarios in which we need to create a Distributed Transaction

Any connection to Sql Server 2000, Sql Server 7 or Oracle, these backends do not support delegated transactions.

Any two enlistments, ex. Open two connections to Sql Server 2005, open a connection to SqlServer 2005 and enlist into msmq etc.

Using an extrictly delegated transaction, i.e. if you only connect to a single Sql Server 2005 server, has roughly the same performance you may expect from a local transaction with the same isolation level.

You can also manually enlist into a distributed transaction, this api looks much more like traditional Transaction code:

using System;

using System.Data.SqlClient;

using System.Transactions.Ltm;

using System.Transactions;

namespace DataViewer.Repro {

public class Repro {

public static int Main(string[] args) {

ICommittableTransaction icommittabletransaction1 = Transaction.Create(); // LightweightCommittableTransaction

using (SqlConnection sqlconnection1 = new SqlConnection(ConnectionString)){

sqlconnection1.Open();

sqlconnection1.EnlistTransaction((ITransaction)icommittabletransaction1);

//Do your work here

}

icommittabletransaction1.Commit();

return 1;

}

Here we are creating a lightweight transaction, this does not create a DTC. When we call EnlistTransaction to manually enlist in the lightweight transaction we will get different behavior depending on the backend. Against Sql Server 2005 we will recognize that it supports promotable transactions and the transaction will continue to be lightweight. If this was Sql Server 2000, Sql Server 7 or Oracle, or if we had enlisted previously into another resource, the lightweight transaction would automatically be promoted to a Distributed transaction.

Useful tip, look at the start->control panel->administrative tools->Component Services->Component Services->Computers->MyComputer->Distributed Transaction Coordinator -> Transaction Statistics

To monitor promoted transactions. You will only be able to see transactions here if they have been promoted.

Standard Disclaimer, All information posted here is “AS IS” and confers no rights. This is not a finished article and it is very likely going to contain some errors.