In the next four posts, we will be building a barebones project to demonstrate WCF’s support for Transactions.
The other posts in this series are:
WCF Transactions – Barebones Demo – Part 1 (Tools)
WCF Transactions – Barebones Demo – Part 2 (Service Code)
WCF Transactions – Barebones Demo – Part 3 (Client Code)
WCF Transactions – Barebones Demo – Part 4 (Analysis)
You can download the source code for the series from here.
The demo focuses on the usage of these properties:
- TransactionScopeRequired (of the OperationalBehavior attribute)
- TransactionFlow (of some of the Binding classes)
- TransactionFlowOption (of the TransactionFlow attribute)
Hopefully, this demo will get you up and running and you can then easily use it to test other properties and behaviors that are not shown.
To operate the demo, you will not be needing an SQL server or any other resource manager, because we will build one ourselves. (A resource manager is the name given to objects that can enlist in transactions to commit and rollback changes made to a resource).
For a more in depth discussion of Volatile Resource Managers and a guide to implementing transactional types I recommend reading Volatile Resource Managers in .NET Bring Transactions to the Common Type by Juval Lowy.
In the next post I will introduce the VolatileResourceManager which, is what’s its name suggests. It implements the IEnlistmentNotification interface. It is simpler and has less functionality than Transaction<T> described in Juval’s article. However, it is sufficient for our purposes. I said barebones, right ? : )
As we have the source code for the VolatileResourceManager, we can easily see the commits and rollbacks (or lack thereof) that are generated by transactional (or non-transactional) code that uses it.
We will also want to see whether a transaction in which the VolatileResourceManager participates is a local or distributed transaction, and whether the transaction flowed from the client or was created locally within the service. To assist with this, I also implement an extension function to the Transaction class that displays this information about a transaction.
So far, no WCF.
In the third and fourth posts in this series, I will implement the Service and Client code respectively. Also in the fourth post, we will write code to use the VolatileResourceManager in a transactional operation that rolls back. The code will do so once against a local implementation of the class and a second time across a WCF service boundary.
This is where we will be able to observe how transactions flow (or not) from a WCF client to a WCF service.
The fifth post runs the demo and discusses the results.