ADO.NET Distributed transactions, loose ends.

  • Artykuł

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

Comments

  • Anonymous
    July 16, 2004
    What about Attribute based Transaction Scopes to Methods and Classes? Would that be available in the future or is it part of Indigo?

    Krishna
  • Anonymous
    July 16, 2004
    I am not sure I understand the question, it sounds like you liked the [Autocommit] and [TransactionOption=REQUIRESNEW] properties that we have when we derive from EnterpriseServices. You have to realize that we did not get this for free, the reason this worked was because we made you derive from EnterpriseServices, add a strong name to your assembly and make it COM visible.

    I am much happier with the new model and I hope it does not change, please note that there is nothing stopping you from using the old attribute based transaction model.
  • Anonymous
    July 16, 2004
    Yes it was about the [Autocommit] and [TransactionOption] properties. I remember seeing similar attributes in a presentation from the PDC on Distributed Transactions using the Light weight Transaction Manager.

    We are using Remoting interception (derived from ContextBound and applied ContextAttributes) for Distributed Transactions without using EnterpriseServices. Since these classes are not documented and might become internal in future releases of the framework we want to move away from this model and use the System.Transaction classes instead, so we were comparing the options available and wanted to know if similar attributes would be made available in the future...basically we are looking for applying the "using TransctionScope" block through attributes and avoid having to write the plumbing code...

    Thanks !
  • Anonymous
    July 26, 2004
    Krishna,
    I am sorry it's taken me this long to get back, but it has not been easy to get any concrete information.

    The discusion at the PDC was for attribute based transactions for Indigo rather than Whidbey and that they tend to come as part of more complete environments than System.Transactions.

    System.Transactions is a lower level set of features to enable transaction support.
    Hope this helps.
  • Anonymous
    June 07, 2009
    PingBack from http://greenteafatburner.info/story.php?id=4206