Transaction Protocols and Managers

By and large, WCF developers need never concern themselves with transaction protocols and transaction managers. You should rely on WCF (and .NET) to select the correct protocol and transaction manager, and focus instead on implementing your logic. However, I have found that developers typically care a great deal about this issue, so I’ve chosen to include a discussion of transaction protocols and managers (mostly to demonstrate that there is no practical reason to actually deal with them in the first place).

The transaction management protocol WCF chooses depends on the execution scope of the participating parties in the transaction. The word protocol may be misleading here, because in the abstract the protocol being used is the two-phase commit protocol. The differences between the transaction management protocols have to do with the type of remote calls and communication protocol used, and the kind of boundaries it can cross. The options are:

The lightweight protocol

This protocol is used to manage transactions in a local context only, inside the same app domain. It cannot propagate the transaction across the app domain boundary (let alone the process or machine boundary), nor can it flow the transaction across any service boundary (that is, from a client to a service). The lightweight protocol is used only inside a service or between two parties in the same app domain, never between services. The lightweight protocol yields the best performance compared with the other protocols.

The OleTx protocol

This protocol is used to propagate transactions across app domain, process, and machine boundaries, and to manage the two-phase commit protocol. The protocol uses RPC calls, and the exact binary format of the calls is Windows-specific. As a result of the use of both the RPC and the Windows-specific format, it cannot be used across firewalls or to interoperate with non-Windows parties. This is usually not a problem, because the primary use for the OleTx protocol is for managing transactions in an intranet, in a homogeneous Windows environment.

The WS-Atomic Transaction (WSAT) protocol

This protocol is similar to the OleTx protocol in that it too can propagate transactions across app domain, process, and machine boundaries and can be used to manage the two-phase commit protocol. However, unlike the OleTx protocol, the WSAT protocol is based on an industry standard and can typically be used across firewalls. Although you can use the WSAT protocol in an intranet in a heterogeneous environment, its primary use is for transaction management across the Internet, where multiple transaction managers are involved.

Protocols and Bindings

No binding supports the lightweight protocol, because the protocol cannot propagate transactions across the service boundary anyway. However, the various transaction-aware bindings differ in their support for the two other transaction-management protocols. The TCP and IPC bindings can be configured to work with both the OleTx and WSAT protocols, or with just one of them. Both bindings default to the OleTx protocol and will switch to the WSAT protocol if required. In addition, these two intranet bindings let you configure the protocol either in a config file or programmatically, like any other binding property.

WCF provides the TransactionProtocol abstract class, defined as:

public abstract class TransactionProtocol
{
   public static TransactionProtocol Default
   {get;}
   public static TransactionProtocol OleTransactions
   {get;}
   public static TransactionProtocol WSAtomicTransactionOctober2004
   {get;}
   public static TransactionProtocol WSAtomicTransaction11
   {get;}
}

Both the TCP and IPC bindings offer the TransactionProtocol property of the matching type. For example:

public class NetTcpBinding : Binding,...
{
   TransactionProtocol TransactionProtocol
   {get;set;}
   //More members
}

To set the protocol programmatically, first construct the specific binding type, then set the property using one of the static methods:

NetTcpBinding tcpBinding = new NetTcpBinding();
//Protocol only matters with propagation
tcpBinding.TransactionFlow = true;
tcpBinding.TransactionProtocol =
                               TransactionProtocol.WSAtomicTransactionOctober2004;

Note that the transaction protocol configuration is meaningful only when transaction propagation is enabled as well.

To configure the protocol in a config file, define a binding section as usual:

<bindings>
   <netTcpBinding>
      <binding name = "TransactionalTCP"
         transactionFlow = "true"
         transactionProtocol = "WSAtomicTransactionOctober2004"
      />
   </netTcpBinding>
</bindings>

When you configure a protocol for the TCP or IPC binding, the service and the client must use the same protocol.

Since the TCP and IPC bindings can be used only in an intranet, there is really no practical value to configuring them for the WSAT protocol, and this ability is available largely for the sake of completeness.

The WS bindings (WSHttpBinding, WS2007HttpBinding, WSDualHttpBinding, WSFederationHttpBinding, and WS2007FederationHttpBinding) are designed for use across the Internet, when multiple transaction managers are involved, using the WSAT protocol. However, in an Internet scenario where only a single transaction manager is involved, these bindings will default to the OleTx protocol. There is no need or ability to configure a particular protocol.

Transaction Managers

Recall from the discussion at the beginning of this chapter that the last thing you should do is manage a transaction yourself. The best solution is to have a third party, called the transaction manager, manage the two-phase commit protocol for your clients and services. WCF can work with not one but three different transaction managers in a provider model, as shown in Figure 7-4.

WCF transaction managers

Figure 7-4. WCF transaction managers

The three transaction managers are the Lightweight Transaction Manager (LTM), the Kernel Transaction Manager (KTM), and the Distributed Transaction Coordinator (DTC). As a function of the platform used, what the application does, the services it calls, and the resources it consumes, .NET (and Windows) will assign the appropriate transaction manager. Because the transaction manager is assigned automatically, your code is decoupled from the transaction management and from the transaction protocol used. Again, developers need never bother themselves with the transaction managers, and the following discussion is intended only to alleviate some common concerns regarding performance and efficiency.

The LTM

The LTM can manage only a local transaction; that is, a transaction inside a single app domain. The LTM uses the lightweight transaction protocol to manage the two-phase commit protocol. It can only manage a transaction that involves at most a single durable resource manager. The LTM can also manage as many volatile resource managers as are present. If only a single resource manager is present, and that resource supports single-phase commit, the LTM will use that optimized protocol. Most importantly, the LTM can only manage a transaction inside a single service, and only when that service does not flow the transaction to other services. The LTM is the most performant transaction manager, on a par performance-wise with performing direct transactions against the resource.

The KTM

The 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). The KTM uses the lightweight transaction protocol over both direct memory and kernel calls. The KTM can only manage the transaction if it involves at most a single durable KRM, but the transaction can have as many volatile resource managers as desired. As with the LTM, the transaction can involve at most one service, as long as that service does not propagate the transaction to other services.

The DTC

The DTC is capable of managing transactions across any execution boundary, from the most local (a transaction within the same app domain) scope to the most remote (a transaction that crosses process, machine, or site boundaries). The DTC can use either the OleTx or the WSAT protocol. The DTC is the transaction manager used when transactions flow across the service boundary. The DTC can easily manage a transaction that involves any number of services and resource managers.

The DTC is a system service available by default on every machine running WCF, and WCF (and .NET) is tightly integrated with the DTC. The DTC creates new transactions, collects the votes of the resource managers, and instructs the resource managers to abort or commit the transaction. For example, consider the application shown in Figure 7-5, where a nontransactional client calls to a service on Machine A. The service on Machine A is configured to use a transaction. That service becomes the root of the transaction, and it will get the opportunity not just to start the transaction but also to indicate when the transaction is done.

A DTC-managed transaction

Figure 7-5. A DTC-managed transaction

Note

Every transaction in WCF has at most one root service, because a non-service client can also be the root of the transaction.

When a service that is part of a transaction on Machine A tries to access another service or a resource on Machine B, it actually has a proxy to the remote service or resource. That proxy propagates the transaction ID to Machine B. The call interception on Machine B contacts the local DTC on Machine B, passing it the transaction ID and informing it to start managing that transaction on Machine B. Because the transaction ID gets propagated to Machine B, resource managers on Machine B can now auto-enlist in it. Similarly, the transaction ID is propagated to Machine C.

When the transaction is done, if the combined services’ vote was to try to commit the transaction, it is time to start the two-phase commit protocol. The DTC on the root machine collects the resource managers’ votes on that machine and contacts the DTC on every other machine that took part in the transaction, instructing them to conduct the first phase on their machines. The DTCs on the remote machines collect the resource managers’ votes on their machines and forward the results back to the DTC on the root machine. After the DTC on the root machine receives the results from all the remote DTCs, it has the combined resource managers’ vote. If all of them vote to commit, the DTC on the root machine again contacts all the DTCs on the remote machines, instructing them to conduct phase two on their respective machines and to commit the transaction. If even one resource manager voted to abort the transaction, however, the DTC on the root machine informs all the DTCs on the remote machines to conduct phase two on their respective machines and to abort the transaction. Note that only the DTC on the root machine has the combined vote of phase one, and only it can instruct the final abort or commit.

Transaction Manager Promotion

.NET dynamically assigns the appropriate transaction manager for the transaction. If one transaction manager is inadequate, .NET will promote the transaction; that is, ask the next-level-up transaction manager to handle the transaction. A single transaction can be promoted multiple times. Once promoted, the transaction stays elevated and cannot be demoted. The previous transaction manager used to manage the transaction is relegated to a pass-through mode. Because of this dynamic promotion, developers are precluded from interacting with the transaction managers directly (doing so would bypass promotion). Promotion is yet another reason why you should not write code such as that in Example 7-1: it eliminates any chance of promotion.

LTM promotion

Every transaction in .NET always starts out as a transaction managed by the LTM. As long as the transaction interacts with a single durable resource and as long as there is no attempt to flow the transaction to a WCF service, the LTM can manage the transaction and yield the best throughput and performance. The LTM can manage as many volatile resource managers as required. However, if the transaction tries to enlist a second durable resource or the transaction is propagated to a service, .NET will promote the transaction from the LTM to the DTC. Another type of promotion takes place if the first durable resource accessed is a KTM resource, in which case .NET (actually, Windows itself) will promote the transaction from the LTM to the KTM.

KTM promotion

The KTM can manage a transaction as long as it interacts with a single KRM and as long as the transaction is local. The KTM can manage as many volatile resource managers as required. The KTM transaction is promoted to the DTC when the transaction flows to another service or if a second durable resource (kernel or regular) is enlisted.

Resources and promotion

At the time of this writing, the only resources that can participate in an LTM transaction and promote from it are volatile resource managers and the various flavors of SQL Server, from SQL Server 2005 and later. Legacy resource managers such as SQL Server 2000, Oracle, DB2, and MSMQ can only participate in DTC transactions. Consequently, when a legacy resource is accessed by an LTM transaction, even if it is the single resource in the transaction, the transaction is automatically promoted to the DTC.

The relationship between resources and transaction managers is summarized in Table 7-1.

Table 7-1. Resources and transaction managers

Resource

LTM

KTM

DTC

Volatile

Yes

Yes

Yes

SQL Server 2005/2008

Yes

No

Yes

Kernel

No

Yes

Yes

Any other RM

No

No

Yes

Note

With an Oracle database, ODP.NET Release 10.2.0.3 can support a local LTM transaction only or a distributed DTC transaction only, but cannot promote from the LTM to the DTC. An LTM transaction encountering a promotion event is not promoted to the DTC, but rather aborts with an exception. A transaction can also be configured to always start as a DTC transaction.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.222.196.175