System.Transactions is ready to change the way you write distributed code!
Hi everyone! It's been a while since I started up this blog and for the most part, it's been dormant. This is because the product I work on, System.Transactions, had never been shipped so there were concerns about us talking about it publicly. However, now that Whidbey Beta 1 is available for download, the cat is out of the bag, and it's time to get rockin'!
First order of business is: What is System.Transactions? The answer: System.Transactions is a new framework library that helps you write distributed, transacted applications in .NET. System.Transactions seeks to be fast, lightweight and easy to use.
So, let's jump right in! To get started, you'll need to add “using System.Transactions“ to the top of your source code file (and reference System.Transactions.dll when building your assemblies). Then, to create a transaction, simply do:
ICommittableTransaction myTx = Transaction.Create();
Let's take a few seconds to check out what is going on here. First, you'll notice that instead of using a constructor, I'm calling a static factory method on the Transaction class. This is because System.Transactions implements a layer of abstraction between the user program and the underlying transaction infrastructure. It allows us to update, enhance and extend the underlying implementation in the future without changing any of your code on top.
Next, you'll notice that I am getting back an object that implements the ICommittableTransaction interface. This interface has many of the standard properties and methods you'd expect on a transaction (and probably a few that you're unfamiliar with). The most important one that we'll look at today is the Commit() method. As the initiator of the transaction, your code has control of when the transaction commit will be requested of the transaction manager. Thus, you get an ICommittableTransaction. Other components that you pass your transaction to will naturally want to do work in the transaction, but you will not want them to have commit ability on your transaction. To this end, they are given an ITransaction object; ICommittableTransaction and ITransaction look identical except for one major difference: ICommittableTransaction has the Commit() method.
Now that you have a transaction, you'll most likely want to pass it to other components so that they can do work on it. We have made the objects backing your ICommittableTransaction serializable. This means you can directly pass your transactions through .NET Remoting and your transaction will be automatically marshaled to the other side. No more playing with whereabouts, transaction cookies and/or propagation tokens; everything happens through the magic of the ISerializable interface!
Congratulations, you've just had your first 30 second intro to playing with System.Transactions. I know what you're all thinking: “thanks Mark, this is all well and good, but how do I get some work done in this transaction?” To that, I say: stay tuned for my next installment, where I'll cover the details on how to enlist in the transaction and we'll get down to business - business logic that is :-p