7.4. Transaction Protocols and ManagersDepending on the execution scope of the participating parties in the transaction, WCF will use a different transaction management protocol. 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.
7.4.1. Protocols and BindingsNo binding supports the lightweight protocol, because the protocol cannot propagate the transaction 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 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;} } Both the NetTcpBinding and the NetNamedPipeBinding 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 only meaningful 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 only be used in an intranet, there is really no practical value for configuring them for the WSAT protocol, and this ability is available largely for completeness' sake. The WS bindings (WSHttpBinding, WSDualHttpBinding, and WSFederationHttpBinding) are designed for use across the Internet, when multiple transaction managers are involved using the WSAT protocol. However, in an Internet scenario when only a single transaction manager is involved, these bindings will default for the OleTx protocol. There is no need or ability to configure a particular protocol. 7.4.2. Transaction ManagersRecall from the discussion at the beginning of this chapter that the last thing you should do is manage the 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, shown in Figure 7-4. 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, WCF will assign the appropriate transaction manager. By automatically assigning the transaction manager, WCF decouples the transaction management from service code and from the transaction protocol used. Developers need never bother themselves with the transaction managers, and the following discussion is only intended to alleviate some common concerns regarding performance and efficiency. 7.4.2.1. The LTMThe LTM can only manage 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 present. If only a single resource manager is present, and that resource supports single-phase commit, then 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. 7.4.2.2. The KTMThe KTM can be used to manage transactional kernel resource managers (KRM) on Windows Vista, specifically the transactional filesystem (TXF) and the transactional registry (TXR). The KTM uses the lightweight transaction protocol over both direct memory and kernel calls. The KTM can manage the transaction as long as it involves at most a single durable KRM, but the transaction can have as many volatile resource managers as desired. Similar to the LTM, the transaction can involve at most one service, as long as that service does not propagate the transaction to other services. 7.4.2.3. The DTCThe DTC is capable of managing a transaction across any execution boundary, from the most local (such as the same app domain) across all boundaries, such as process, machine, or site boundaries. The DTC can use either the OleTx or the WSAT protocols. 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 as desired. The DTC is a system service available by default on every machine running WCF. The DTC is tightly integrated with WCF. The DTC is the one that creates new transactions, propagates transactions across machines, collects the votes of the resource managers, and instructs the resource managers to roll back or commit. For example, consider the service-oriented 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. Figure 7-5. DTC managed 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 interception on Machine B contacts the local DTC on Machine B, passing it the transaction ID, 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 with 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, then it is time to start the two-phase commit protocol. The DTC on the root machine collects the resource managers' votes on the root machine and contacts the DTC on every 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, then 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, then 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. 7.4.3. Transaction Manager PromotionWCF dynamically assigns the appropriate transaction manager for the transaction. If one transaction manager is inadequate, WCF 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 the dynamic promotion, developers are precluded from interacting with the transaction managers directly, because that would bypass promotion. Promotion is yet another reason why you should not write code such as Example 7-1, because it precludes any chance of promotion. 7.4.3.1. LTM promotionEvery transaction in WCF 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. However, if the transaction tries to enlist a second durable resource or the transaction is propagated to a service, WCF 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 WCF will promote the transaction from the LTM to the KTM. 7.4.3.2. KTM promotionThe 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 when any second durable resource (kernel or regular) is enlisted. 7.4.3.3. Resources and promotionAt the time of this writing, the only resources that can participate in an LTM transaction are volatile resource managers and the various flavors of SQL Server 2005. Legacy resource managers such as SQL Server 2000, Oracle, DB2, and MSMQ can only participate in a DTC transaction. 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.
|