2.0 changes in latest community drop.

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 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.

Comments (13)
  1. I like those changes, especially that you have added the Complete() method 🙂

  2. Angel says:


    I agree, the Complete() method is a great improvement and it will result in easier to write/read/debug code. I am actually kind of surprised you picked this out from deep inside my post though 🙂 I have no ilusions about people actually reading these things.

  3. John Lewicki says:

    Dont kid yourself, I read the posts with great interest…

  4. Bill says:

    1 & 2 kick a33

  5. Peter says:

    Since the Guid now returns null, I can no longer use it to force a lightweight transaction to promte itself to a DTC transaction.

    OleDB/ODBC do not auto-enlist, so what’s the trick to get this working in a transactionscope?

  6. Angel says:


    Hopefully we will get Oledb and Odbc to autoenlist (or rather, to look like they do) for you. The way we are doing this is to check for a Transaction Current tx after connection open and manually enlisting the new connection into this tx. The problem we are finding with this approach is that manually enlisting Odbc connections (and in some instances Oledb and SqlClient) to Sql Server 7 has some problems that we don’t find when autoenlisting.

    If you are using Sql2k or Oracle you should be able to manually enlist withouth problems today.


    Thanks for your comments, I take it that you are not particularily impressed with point 3? 🙂 This is actually a good thing just in the sheer number of bugs it will save, but cutting stuff is always hard. Somebody will always have a use for a feature taht you can’t even imagine. Let me know if this is the case with ExecuteRow.

    Well, I am on vacation and can’t even log into my blog (what was that password again) so a few extra changes in my next comment.

  7. Angel says:

    Some more important changes:

    AdapterBatchUpdate has been completelly reworked. We are no longing manually batching commands in SqlClient since this runs into a 2100 parameter limit with the sp_executesql stored procedure. You will now be able to batch as many rows as you want without restriction. As before you will find that there is an optimum batch size that will maximize perofrmance for your particular scenario/setup.

    SqlBulkCopy now allows bulk copying to temp tables.

    The providerbase classes have been removed. This is unfortunate but will only affect provider writers. When doing performance testing we realized that this gets too much in the way. The other problem is that we really don’t have a customer for these classes and they weren’t shapping up the way we wanted. This is a shame because I know that some people have already started working on providers based on these classes like bob beauchemins excelent example. It hurts me more directly since I had written my own provider to test pooling.

    Rambling out, standard disclaimer. This post is provided AS IS and cofers no rights.

  8. Sahil Malik says:

    Angel, I have to say ; your blog contains a TONNE Of valuable information. I discovered it a bit too late, but I am reading thru each entry one by one backwards !!!

    Lets get Sushil blogging – I’ve really liked his answers in the NewsGroups. Is his email addy sushilc at mdollar dot com? If it is, I am gonna write him a personal email and implore him to start blogging.

  9. Angel says:


    Thanks for the feedback, very much appreciated. I am a long time subscriber to your blog (excelent feedback btw!).

    I would also like to see Sushil blogging more regularly, he keeps threatening to start with notifications and it would be a great resource, it is a great feature but it has more gotchas than just about everything else we are shipping this relase. He also owns log shipping failover and some very cool express features that I would love to see described in blog format.

    I have talked to Pablo Castro and David Sceppa about the posibility of creating a data access blog to cover all of our teams bloggers. This may encourage people who would not have the time to get a blog going to post an occasional post on their specific area.

  10. Bill says:


    I know the first problem is that I forgot I had it in a for loop. But if you get a chance, can you elaborate on the NextResult method in the DataTableReader? It seems like it’s only using the last GetReader value – so how would you create a scenario where you could actually use NextResult?



  11. rape stories says:

    Best of the text i read about a problem.

  12. gay rape says:

    We are wellocme to it’s configuration.

Comments are closed.

Skip to main content