Introduction to Transactions in WCF

Couple of months back I have blogged about SQL Server Transactions. Last few days I have spent some quality time with the book Professional WCF 4: Windows Communication Foundation with .NET 4 and today I am going to write about what I learnt about Transactions in WCF. Since most of the things in this post will be theoretical things, you might feel bored. But I am sure, you will find some pretty interesting things here.

A transaction is a set of operations, in which if single operation fails, the entire set of operations are set to fail, as one atomic operation. Transactions are the best way to maintain consistency in a system. Let’s take a look at the following scenario where the system is transferring from state A to state B, as a result of series of operations.

States of a Transaction

In here State A and B are two consistent states. Before the transaction, the system is on State A and after completing the transaction the systems’ state changes into B.

When considering the above scenario, there can be three transaction types. Committed, Aborted and In-Doubt transaction. If the transaction manages to successfully transfer the system from State A to State B, then it is a Committed Transaction. If the transaction did not manage to transfer the system from State A to State B, and returned to State A, then it is an Aborted Transaction. Finally If the transaction failed to either commit or abort, then it is an In-Doubt transaction.

WCF services can work directly against any transactional resource. WCF also provides a programming model (as on offered by ADO.NET) to manage the transaction explicitly.

Mainly transactions have these four properties which are abbreviated as ACID.

• Atomic
  • Atomic means that all the work in the transaction is treated as a single unit. That is either all statements in the unit must execute, or no statement in the unit must execute.
• Consistent
  • Consistent means that a completed or roll backed transaction leaves the system in a consistent internal state. A transaction will convert the system from a known starting state to a known ending state. If the transaction commits, the database will be at the known ending state. If the transaction fails, the system will be at the known starting state.
• Isolated
  • Isolation means that the transaction sees the system in a consistent state. If two transactions try to update the same resource, one will go first and then the other will follow. Transactions are committed independently from each other and they are transparent to each other.
• Durability
  • Durability means that the results of the transaction are permanently stored in the system and ensures that the result or effect of a committed transaction persists in case of a system failure.

WCF Transactions

Distributed Transactions

A distributed transaction contains two or more independent services or even just a single service with two or more transactional resources. Let’s take the following design. We have an infrastructure where a client communicates with multiple services and these services interact with each other and with multiple resources.

Distributed Transaction

In here, we are facing two questions determining,

1. Who will start the transaction and how others are going to know about the initiator? If everyone started transactions there will be many transactions.
2. Who will instruct the transaction to either to commit or rollback?

In this kind of distributed transaction if you try to write the logic for transaction management, you will not be able to concentrate on your systems' logic. So you will need to rely on something. Now comes the Two-Phase Commit Protocol and the Transaction Manager to the picture. A transaction manager is a third party and will manage the transaction of the clients and services for you. Transaction manager takes the decision either to commit or rollback based on a transaction management protocol which is the two-Phase Commit protocol.

Transaction protocols used in Bindings

WCF chooses transaction management protocol based on the execution scope of the participating parties in the transaction. Please note that since I am using the term protocol here, this has nothing to do with two-Phase Commit protocol. These are used in bindings as the values for transactionProtocol.

1. The Lightweight protocol
   • This protocol is used to manage transactions in a local context only, inside the same application domain.
   • The lightweight protocol is used only inside a service.
   • Never between services.
   • No binding supports the lightweight protocol.
2. The OleTx protocol
   • This protocol is used to propagate transactions across application domain, process, and machine boundaries, and to manage the two-phase commit protocol.
   • Windows-Specific / Only in Windows environment.
   • Cannot be used across firewalls or to interoperate with Non-Windows parties.
   • TCP and IPC (Inter Process Communication) bindings uses OleTx protocol as the default and will switch to the WSAT protocol if required.
3. The WS-Atomic Transaction (WSAT) protocol
   • Same as OleTx protocol.
   • Can be used across firewalls.
   • Non Windows-Specific.
   • The WS bindings are designed for use across the Internet, when multiple transaction managers are involved, using the WSAT protocol. (In an Internet scenario where only a single transaction manager is involved, these bindings will default to the OleTx protocol.)

Transaction Manager

WCF can work with three different transaction managers which are Lightweight Transaction Manager (LTM), the Kernel Transaction Manager (KTM), and the Distributed Transaction Coordinator (DTC). .NET will assign the appropriate transaction manager based on the platform used, what the application does, the services it calls, and the resources it consumes. Since the transaction manager is assigned automatically, the code is decoupled from the transaction management and from the transaction protocol used.

1. Lightweight Transaction Manager (LTM)
   • Can only manage local transaction (inside a single application domain).
   • Can only manage a transaction inside a single service, and only when the service does not flow the transaction to other services.
   • Uses the lightweight transaction protocol to manage the two-phase commit protocol.
   • Most performing transaction manager.
2. Kernel Transaction Manager (KTM)
   • Can be used to manage transactional kernel resource managers (KRMs) on Windows Vista, Windows Server 2008, and Windows 7 or later-specifically, the transactional files system (TxF) and the transactional registry (TxR).
   • Uses the lightweight transaction protocol.
3. Distributed Transaction Coordinator (DTC)
   • Can manage transactions across any execution boundary, from the most local (a transaction within the same application domain) scope to the most remote (a transaction that crosses process, machine, or site boundaries).
   • Use either the OleTx or the WSAT protocol.
   • The DTC is the transaction manager used when transactions flow across the service boundary.
   • The DTC is a system service available by default on every machine running WCF, and WCF (and .NET) is tightly integrated with the DTC.

Two-Phase Commit Protocol

As the name means, this protocol has two phases.

1. Commit Request / Voting
   • In this phase transaction manager requests the votes from all the participants to start a transaction.
   • Every participant replies with either Commit or Abort.
   • Once a vote has been made, it cannot be reversed.
2. Commit / Complete
   • If every participant vote is for commit, then transaction is instructed to commit.
   • If single participant has voted to abort, then the transaction is instructed to abort and rollback.

Transaction Propagation

WCF can propagate transactions across the service boundary. Because of this, a one or more services can participate in a client’s transaction. In here client can be either a WCF or any other application. Both the binding and the operation contract take the decision on whether to or not to propagate on the client’s transaction. Only the TCP, IPC, and WS bindings have the ability to propagate client’s transactions.

Now comes the practical things, so I will stop now. Hope you all got a good understanding about these and will see these in action in a coming post.

Happy Coding.

Regards,

Jaliya