博客园-Artech

如何通过VPC在本机搭建局域网

Artech — Sun, 07 Feb 2010 16:06:00 GMT

阅读: 985 评论: 14 作者: Artech 发表于 2010-02-08 00:06 原文链接

前几天在家里测试一个基于WS-AT的分布式应用，但是连接公司网络的VPN出现了问题，不得不采用VPC在本机搭建一个局域网。虽然以前也做过这样的尝试，可能是很久没有弄过了，一些细节记不清了，所以也折腾了好一阵子。在这里，我特意写一篇文章来介绍基于VPC搭建局域网的整个步骤，没有什么技术含量，只当给具有相同需要的朋友多一个参考。

我现在的Host Machine为Windows 7 Ultimate （X64），Virtual Machine为Windows Server 2008 （X86），都是现成的。本篇文章不会涉及如何安全VPC的问题，仅仅涉及到如何将Host PC和VPC成为同一个局域网中两台可以互相链接的主机，下面是对3个主要步骤的：

步骤一：安装Microsoft Loopback Adapter网络适配器

打开Device Manager，右键选择主机名称，在探出的上下文菜单中选择"Add legacy hardware”。

出现如下一个Welcome to the Add Hardware Wizard 对象框，点击"Next”按钮。

进入如下一个对话框，选择第二个选项"Install the hardware that I manually select from a list (Advanced) "，然后点击"Next"按钮。

弹出如下一个硬件类型选择对话框，硬件类型列表中选择"Network adapter"，然后点击"Next"按钮。

硬件安装向导进入如下一个"Select Network Adapter",在硬件厂商列表中选择"Microsoft",在网络适配器列表中选择"Microsoft Loopback Adapter",然后点击"Next"按钮。

在弹出的"The wizard is ready to install your hardware"对话框中，然后点击"Next"按钮，开始安装硬件。

步骤二、将VPC的网络适配器设置为Microsoft Loopback Adapter

打开Virtual PC Console，选择相应的VPC，点击Setting按钮对其进行设置。

在VPC设置面板中设置项目中选择"Networking",选择我们刚才安装的"Microsoft Loopback Adapter"作为网络适配器，点击OK确认。

步骤三、设置Host Machine和Virtual Machine的IP

在Host Machine中，打开Network and Sharing Center，点击Channe Adapter Setting链接，进入Network Connections窗口。

右击选择基于Microsoft Loopback Adapter的连接（这里是Local Area Connection 2），在上下文菜单中选择Proeprties，进入连接的属性窗口。

选择Internet Protocol Version 4（TCP/IPv4),点击 Properties按钮，进行相应的IP设置，在这里IP地址和子网掩码分别为192.168.0.6和255.255.255.0.

然后对Virtual Machine相应的链接按照上面的步骤设置IP地址，需要设置成相同的网段，我采用的IP地址和子网掩码分别为192.168.0.8和255.255.255.0.

到此为止，Host Machine和Virtual Machine就成为了同一个局域网中的两个主机。你可以直接利用VPC界面操作Virtual Machine，不过我个人习惯使用Remote Desktop。此外，你可以根据具体安全需求，对防火墙进行相应设置。

作者：Artech
出处：http://artech.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

评论: 14　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

谈谈分布式事务（Distributed Transaction）[共5篇]

Artech — Sun, 31 Jan 2010 05:22:00 GMT

阅读: 432 评论: 2 作者: Artech 发表于 2010-01-31 13:22 原文链接

[第1篇] SOA需要怎样的事务控制方式

在一个基于SOA架构的分布式系统体系中，服务（Service）成为了基本的功能提供单元，无论与业务流程无关的基础功能，还是具体的业务逻辑，均实现在相应的服务之中。服务对外提供统一的接口，服务之间采用标准的通信方式进行交互，各个单一的服务精又有效的组合、编排成为一个有机的整体。在这样一个分布式系统中某个活动（Activity）的实现往往需要跨越单个服务的边界，如何协调多个服务之间的关系使之为活动功能的实现服务，涉及到SOA一个重要的课题：服务协作（Service Coordination）。而具体来讲，一个分布式的活动可能会执行几秒钟，比如银行转帐；也可能执行几分钟、几个小时、几天甚至更长，比如移民局处理移民的申请。事务，无疑是属于短暂运行服务协作（Short-Running Service Coordination）的范畴。

[第2篇] 基于DTC的分布式事务管理模型之事务控制角色

通过上一篇的介绍，我们知道了SOA真正需要的是一个能够协调服务操作直接（通过服务自身访问的资源）或者间接（通过被调用服务访问的资源）访问的所有资源的分布式事务管理系统，这是一个复杂的架构体系。WCF，作为Windows平台下基于SOA的分布式框架，对分布式事务提供全面的支持。不过，WCF并不是另起炉灶，而是充分地利用了Windows现有的事务控制基础架构。本节着重讨论Windows事务处理模型，首先来看看在这个模型中各个事务参与者各自扮演怎样的角色。

[第3篇]基于DTC的分布式事务管理模型之事务登记于基于2PC的事务提交

当基于LTM或者KTM的事务提升到基于DTC的分布式事务后，DTC成为了本机所有事务型资源管理器的管理者；此外，当一个事务型操作超出了本机的范围，出现了跨机器的调用后，本机的DTC需要于被调用者所在机器的DTC进行协助。上级对下级（包括本机DTC对本机所有资源管理器，以及上下级 DTC）的管理得前提是下级在上级那里登记，即事务登记（Transaction Enlist）。所有事务参与者，包括所有资源管理器和事务管理器（即DTC）在进行了事务等级完成之后形成了一个树形的层级结构，该结构的形成是后续的事务提供成为可能，因此我们将其称之为事务提交树（Transaction Commit Tree）。

不同于基于单一资源管理器的本地事务，在一个分布式环境中时实现一个涉及到多个资源管理器的分布式事务，实现事务的ACID四大属性，要麻烦得多。当事务初始化服务（应用或者组件，为了更佳贴近WCF，我们都称服务）完成所有相关的操作，决定提交该事务。对于分布式事务的提交，最终的结果有两个：如果所有的操作能够顺利完成，需要持久化的数据被相应的资源管理器写入到目标资源；如果任何一个环节失败，所有持久化资源管理器将数据恢复到原来的状态。分布式事务的整个提交过程，采用两阶段提交（2PC：Two-Phase）Commit协议完成。顾名思义，“两阶段提交”意味整个整个事务提交阶段分两个阶段，我们现在就来详细介绍分别在这两个阶段中，都在做些什么。

[第4篇]System.Transactions事务之事务（Transaction）和可提交事务（CommittableTransaction）

在.NET 1.x中，我们基本是通过ADO.NET实现对不同数据库访问的事务。.NET 2.0为了带来了全新的事务编程模式，由于所有事务组件或者类型均定义在System.Transactions程序集中的System.Transactions命名空间下，我们直接称基于此的事务为System.Transactions事务。System.Transactions事务编程模型使我们可以显式（通过System.Transactions.Transaction）或者隐式（基于System.Transactions.TransactionScope）的方式进行事务编程。

在System.Transactions事务体系下，事务本身通过类型System.Transactions.Transaction类型表示。只有可提交事务才能被直接初始化，对可提交事务的提交驱动着对整个分布式事务的提交。可提交事务通过CommittableTransaction类型表示。

[第5篇]System.Transactions事务之依赖事务（DependentTransaction）和事务范围（TransactionScope）

Transaction的定义中，信息的读者应该看到了一个叫做DepedentClone的方法。该方法对用于创建基于现有Transaction对象的“依赖事务（DependentTransaction）”。不像可提交事务是一个独立的事务对象，依赖事务依附于现有的某个事务（可能是可提交事务，也可能是依赖事务）。依赖事务可以帮助我们很容易地编写一些事务型操作，当环境事务不存的时候，可以确保操作在一个独立的事务中执行；当环境事务存在的时候，则自动加入其中。

TransactionScope确实能够使我们的事务控制变得非常的简单。实际上，在利用System.Transactions事务进行编程的时候，我们一般不会使用到可提交事务，对于依赖事务也只有在异步调用的时候会使用到，基于TransactionScope的事务编程方式才是我们推荐的。正如其名称所表现的一样，TransactionScope就是为一组事务型操作创建一个执行范围，而这个范围始于TransactionScope创建之时，结束于TransactionScope被回收（调用Dispose方法）。

评论: 2　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

谈谈分布式事务之三: System.Transactions事务详解[下篇]

Artech — Sun, 31 Jan 2010 01:19:00 GMT

阅读: 1269 评论: 8 作者: Artech 发表于 2010-01-31 09:19 原文链接

在前面一篇给出的Transaction的定义中，信息的读者应该看到了一个叫做DepedentClone的方法。该方法对用于创建基于现有Transaction对象的“依赖事务（DependentTransaction）”。不像可提交事务是一个独立的事务对象，依赖事务依附于现有的某个事务（可能是可提交事务，也可能是依赖事务）。依赖事务可以帮助我们很容易地编写一些事务型操作，当环境事务不存的时候，可以确保操作在一个独立的事务中执行；当环境事务存在的时候，则自动加入其中。

一、依赖事务（Dependent Transaction）

依赖事务通过DependentTransaction类型表示，DependentTransaction定义如下。和CommittableTransaction一样，DependentTransaction也是Transaction的子类。既然DependentTransaction依赖于现有的Transaction对象而存在，相当于被依赖事务的子事务，所以无法执行对事务的提交，也自然不会定义Commit方法。但是，DependentTransaction具有一个唯一的方法成员：Complete。调用这个方法意味着向被依赖事务发送通知，表明所有与依赖事务相关的操作已经完成。

   1: [Serializable]   2: public sealed class DependentTransaction : Transaction   3: {     4:     public void Complete();   5: }

1、通过DependentTransaction将异步操所纳入现有事务

通过Transaction的静态属性Current表示的环境事务保存在TLS（Thread Local Storage）中，所以环境事务是基于当前线程的。这就意味着，即使环境事务存在，通过异步调用的操作也不可能自动加入到当前事务之中，因为在异步线程中感知不到环境事务的存在。在这种情况下，我们需要做的就是手工将当前事务传递到另一个线程中，作为它的环境事务。通过依赖事务我们很容易实现这一点。

DependentTransaction通过Transaction的DependentClone方法创建，该方法具有一个DependentCloneOption枚举类型的参数，体现了被依赖的事务再上尚未接受到依赖事务的通知（调用Complete或者Rollback方法）得情况下，提交或者完成所采取的事务控制行为。DependentCloneOption提供了两个选项，BlockCommitUntilComplete表示被依赖事务会一直等待接收到依赖事务的通知或者超过事务设定的超时时限；而RollbackIfNotComplete则会直接将被依赖的事务回滚，并抛出TransactionAbortedException异常。

   1: [Serializable]   2: public class Transaction : IDisposable, ISerializable   3: {          4:     //其他成员   5:     public DependentTransaction DependentClone(DependentCloneOption cloneOption);   6: }   7: public enum DependentCloneOption   8: {   9:     BlockCommitUntilComplete,  10:     RollbackIfNotComplete  11: }

下面的代码演示了如果通过依赖事务，采用异步的方式进行银行转账操作。借助于组件ThreadPool，将主线程环境事务的依赖事务传递给异步操作代理，开始异步操作的时候将此依赖事务作为当前的环境事务，那么之后的操作将自动在当前事务下进行。

   1: private static void Transfer(string accountFrom, string accountTo, double amount)   2: {   3:     Transaction originalTransaction = Transaction.Current;   4:     CommittableTransaction transaction = new CommittableTransaction();   5:     try   6:     {   7:         Transaction.Current = transaction;   8:         ThreadPool.QueueUserWorkItem(state =>   9:         {  10:             Transaction.Current = state as DependentTransaction;  11:             try  12:             {  13:                 Withdraw(accountFrom, amount);  14:                 Deposite(accountTo, amount);  15:                 (state as DependentTransaction).Complete();  16:             }  17:             catch (Exception ex)  18:             {  19:                 Transaction.Current.Rollback(ex);  20:             }  21:             finally  22:             {  23:                 (state as IDisposable).Dispose();  24:                 Transaction.Current = null;  25:             }  26:         }, Transaction.Current.DependentClone(DependentCloneOption.BlockCommitUntilComplete));  27:         //其他操作  28:         transaction.Commit();  29:     }  30:     catch (TransactionAbortedException ex)  31:     {  32:         transaction.Rollback(ex);  33:         Console.WriteLine("转帐失败，错误信息：{0}", ex.InnerException.Message);  34:     }  35:     catch (Exception ex)  36:     {  37:         transaction.Rollback(ex);  38:         throw;  39:     }  40:     finally  41:     {  42:         Transaction.Current = originalTransaction;  43:         transaction.Dispose();  44:     }  45: }

由于在调用DependentClone方法创建依赖事务时指定的参数为DependentCloneOption.BlockCommitUntilComplete，所以主线程在调用Commit方法提交事务的时候，由于依赖事务尚未结束（调用Complete或者Rollback方法），在这里会一直等待。如果依赖事务的Complete或者Rollback一直没有调用，那么被依赖的事务会一直等到超出事务设置的超时时限。所以，对于基于BlockCommitUntilComplete选项创建的依赖事务来说，应该及时地调用Complete或者Rollback方法。

2、通过DependentTransaction实现事务型方法

这里所说的事务型方法是指方法的执行总是在事务中执行。具体来讲，有两种不同的事务应用场景：如果当前不存在环境事务，那么方法的执行将在一个独立的事务中执行；反之，如果存在环境事务，在方法执行会自动加入到环境事务之中。

比如说，存储（Deposit）和提取（Withdraw）就是典型的事务型操作。对于单纯的存取款的场景，应该创建一个新的事务来控制存储和提取操作的执行，以确保单一帐户款项的数据一致性。如果在转账的场景中，应在在转账开始之前就创建一个新的事务，让提取和存储的操作自动加入到这个事务之中。

我们现在就结合可提交事务和依赖事务将Deposit和Withdraw两个方法定义成事务型方法，为了相同代码的重复，在这里把事务控制部分定义在如下一个InvokeInTransaction静态方法中:

   1: static void InvokeInTransaction(Action action)   2: {   3:     Transaction originalTransaction = Transaction.Current;   4:     CommittableTransaction committableTransaction = null;   5:     DependentTransaction dependentTransaction = null;   6:     if (null == Transaction.Current)   7:     {   8:         committableTransaction = new CommittableTransaction();   9:         Transaction.Current = committableTransaction;  10:     }  11:     else  12:     {  13:         dependentTransaction = Transaction.Current.DependentClone(DependentCloneOption.RollbackIfNotComplete);  14:         Transaction.Current = dependentTransaction;  15:     }   16:    17:     try  18:     {  19:         action();  20:         if (null != committableTransaction)  21:         {  22:             committableTransaction.Commit();  23:         }   24:    25:         if (null != dependentTransaction)  26:         {  27:             dependentTransaction.Complete();  28:         }  29:     }  30:     catch (Exception ex)  31:     {  32:         Transaction.Current.Rollback(ex);  33:         throw;  34:     }  35:     finally  36:     {  37:         Transaction transaction = Transaction.Current;  38:         Transaction.Current = originalTransaction;  39:         transaction.Dispose();  40:     }  41: }

InvokeInTransaction方法的参数是一个Action类型的代理（Delegate），表示具体的业务操作。在开始的时候记录下当前的环境事务，当整个操作结束之后应该环境事务恢复成该值。如果存在环境事务，则创建环境事务的依赖事务，反之直接创建可提交事务。并将新创建的依赖事务或者可提交事务作为当前的环境事务。将目标操作的执行（action）放在try/catch中，当目标操作顺利执行后，调用依赖事务的Complete方法或者可提交事务的Commit方法。如果抛出异常，则调用环境事务的Rollback进行回滚。在finally块中将环境事务恢复到之前的状态，并调用Dispose方法对创建的事务进行回收。

借助于InvokeInTransaction这个辅助方法，我们以事务型方法的形式定义了如下的两个方法：Withdraw和Deposit，分别实现提取和存储的操作。

   1: static void Withdraw(string accountId, double amount)   2: {              3:     Dictionary<string, object> parameters = new Dictionary<string, object>();   4:     parameters.Add("id", accountId);   5:     parameters.Add("amount", amount);   6:     InvokeInTransaction(() => DbAccessUtil.ExecuteNonQuery("P_WITHDRAW", parameters));   7: }          8:     9: static void Deposit(string accountId, double amount)  10: {  11:     Dictionary<string, object> parameters = new Dictionary<string, object>();  12:     parameters.Add("id", accountId);  13:     parameters.Add("amount", amount);  14:     InvokeInTransaction(() => DbAccessUtil.ExecuteNonQuery("P_DEPOSIT", parameters));  15: }

二、TransactionScope

在上面一节，我结合可提交事务和依赖事务，以及环境事务的机制提供了对事务型操作的实现。实际上，如果借助TransactionScope，相应的代码将会变得非常简单。下面的代码中，通过TransactionScope对InvokeInTransaction进行了改写，从执行效果来看这和原来的代码完全一致。

   1: static void InvokeInTransaction(Action action)   2: {   3:     using (TransactionScope transactionScope = new TransactionScope())   4:     {   5:         action();   6:         transactionScope.Complete();   7:     }   8: }

通过InvokeInTransaction方法前后代码的对比，我们可以明显看到TransactionScope确实能够使我们的事务控制变得非常的简单。实际上，在利用System.Transactions事务进行编程的时候，我们一般不会使用到可提交事务，对于依赖事务也只有在异步调用的时候会使用到，基于TransactionScope的事务编程方式才是我们推荐的。

正如其名称所表现的一样，TransactionScope就是为一组事务型操作创建一个执行范围，而这个范围始于TransactionScope创建之时，结束于TransactionScope被回收（调用Dispose方法）。在对TransactionScope进行深入介绍之前，照例先来看看它的定义：

   1: public sealed class TransactionScope : IDisposable   2: {   3:     public TransactionScope();   4:     public TransactionScope(Transaction transactionToUse);   5:     public TransactionScope(TransactionScopeOption scopeOption);   6:     public TransactionScope(Transaction transactionToUse, TimeSpan scopeTimeout);   7:     public TransactionScope(TransactionScopeOption scopeOption, TimeSpan scopeTimeout);   8:     public TransactionScope(TransactionScopeOption scopeOption, TransactionOptions transactionOptions);   9:     public TransactionScope(Transaction transactionToUse, TimeSpan scopeTimeout, EnterpriseServicesInteropOption interopOption);  10:     public TransactionScope(TransactionScopeOption scopeOption, TransactionOptions transactionOptions, EnterpriseServicesInteropOption interopOption);  11:       12:     public void Complete();  13:     public void Dispose();      14: }

我们可以看到TransactionScope实现了IDisposable接口，除了Dispose方法之外，仅仅具有一个唯一的方法：Complete。但是TransactionScope却有一组丰富的构造函数。我们先来看看这些构造函数相应的参数如何影响TransactionScope对事务控制的行为。

1、TransactionScopeOption

实际上前面一节中提供的InvokeInTransaction方法基本上体现了TransactionScope的内部实现。也就是说，TransactionScope也是通过创建可提交事务或者依赖事务，并将其作为事务范围内的环境事务，从而将范围的所有操作纳入到一个事务之中。

通过在构造函数中指定TransactionScopeOption类型的scopeOption参数，控制TransactionScope当环境事务存在的时候应该采取怎样的方式执行事务范围内的操作。具有来讲，具有三种不同的方式：

如果已经存在环境事务，则使用该环境事务。否则，在进入范围之前创建新的事务；
总是为该范围创建新事务；
环境事务上下文在创建范围时被取消。范围中的所有操作都在无环境事务上下文的情况下完成。

TransactionScopeOption是一个枚举，三个枚举值Required、RequiresNew和Suppress依次对应上面的三种行为。

   1: public enum TransactionScopeOption   2: {   3:     Required,   4:     RequiresNew,   5:     Suppress   6: }

对于Required选项，如果当前存在环境事务TransactionScope会创建环境事务的依赖事务，负责创建可提交事务，然后将创建的环境事务或者可提交事务作为事务范围的环境事务。如对于RequiresNew选项，TransactionScope总是会创建可提交事务并将其作为事务范围的环境事务，意味着控制事务范围内操作的事务也当前的环境事务已经没有任何关系。如果Suppress选项，TransactionScope会将事务范围内的环境事务设为空，意味着事务范围内的操作并不受事务的控制。

Required是默认选项，意味着事务范围内的事务将会作为当前环境事务的一部分。如果你不希望某个操作被纳入当前的环境事务，但是相应的操作也需要事务的控制以确保所操作数据的一致性。比如，当业务逻辑失败导致异常抛出，需要对相应的错误信息进行日志记录。对于日记的操作就可以放入基于RequiresNew选项创建TransactionScope中。对于一些不重要的操作（操作的错误可被忽略），并且不需要通过事务来控制的操作，比如发送一些不太重要的通知，就可以采用Suppress选项。

2、TransactionOptions和EnterpriseServicesInteropOption

TransactionOptions在前面已经提及，用于控制事务的超时时限和隔离级别。对于超时时限，你也可以选择TransactionScope相应能够的构造函数以TimeSpan的形式指定。而对于事务的隔离级别，需要着重强调一点：当选择TransactionScopeOption.Required选项时，TransactionScope指定的隔离级别必须与环境事务（如果有）相匹配。

比如下面的例子中，我定义两个嵌套的TransactionScope，外部的TransactionScope采用默认的隔离级别，内部在采用ReadCommitted隔离级别，当执行这段代码的时候，会抛出如图1所示的ArgumentException异常。

   1: using (TransactionScope outerScope = new TransactionScope())   2: {   3:     TransactionOptions transactionOptions = new TransactionOptions() { IsolationLevel = IsolationLevel.ReadCommitted };   4:     using (TransactionScope innerScope = new TransactionScope(TransactionScopeOption.Required, transactionOptions))   5:     {   6:         //事务型操作   7:         innerScope.Complete();   8:     }   9:     //事务型操作  10:     outerScope.Complete();  11: }

图1 隔离级别不一致导致的异常

实际上在System.Transactions事务机制被引入之前，像Enterprise Service主要依赖于基于COM+的分布式事务。TransactionScope通过EnterpriseServicesInteropOption控制System.Transactions事务如何与COM+的分布式事务进行互操作。具有来讲具有如下三种互操作选项，分别和EnterpriseServicesInteropOption三个枚举值相对应：

None：Transaction 和 Current 之间不同步；
Automatic：搜索现有的 COM+ 上下文并与之同步（如该上下文存在）；
Full：System.EnterpriseServices 上下文（可通过调用 ContextUtil 类的静态方法 Transaction 来检索）和 System.Transactions 环境事务（可通过调用 Transaction 类的静态方法 Current 来检索）始终保持同步。这将引入性能损失，因为可能需要创建新的 System.EnterpriseServices 上下文。

   1: public enum EnterpriseServicesInteropOption   2: {   3:     None,   4:     Automatic,   5:     Full   6: }

3、事务提交和回滚

对于事务范围中的事务，无论是事务的提交（对于可提交事务）、完成（依赖事务）和回滚都是在Dispose方法中执行的。TransactionScope中定一个个私有的布尔类型字段（complete）表示事务是否正常结束。该成员的默认值为False，当调用TransactionScope的Complete方法的时候会将此字段设置成True。当Dispose执行的时候，如果该字段的值为False，会调用事务的Rollback方法对该事务实施回滚；否则会调用Commit方法（对于可提交事务）对事务进行提交或者调用Complete方法（依赖事务）通知被依赖的事务本地事务已经正常完成。

除了执行事务的提交、完成或者回滚之外，TransactionScope的Dispose方法还负责将环境事务回复到事务范围开始之前的状态。在调用Complete和Dispose之前，环境事务处于不可用的状态，如果此时试图获取环境事务，会抛出异常。比如在下面的代码中，在事务范围内部调用Complete方法后，通过Transaction的Current静态属性获取当前环境事务，会抛出图2所示的InvalidOpertionException异常。

   1: using (TransactionScope transactionScope = new TransactionScope())   2: {   3:     //其他事务操作   4:     transactionScope.Complete();   5:     Transaction ambientTransaction = Transaction.Current;   6: }  

图2 在TransactionScope完成之后获取环境事务导致的异常

分布式事务系列:
谈谈分布式事务之一：SOA需要怎样的事务控制方式
 谈谈分布式事务之二：基于DTC的分布式事务管理模型[上篇]
谈谈分布式事务之二：基于DTC的分布式事务管理模型[下篇]
谈谈分布式事务之三: System.Transactions事务详解[上篇]
谈谈分布式事务之三: System.Transactions事务详解[下篇]

评论: 8　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

谈谈分布式事务之三: System.Transactions事务详解[上篇]

Artech — Sat, 30 Jan 2010 08:49:00 GMT

阅读: 1192 评论: 4 作者: Artech 发表于 2010-01-30 16:49 原文链接

一、System.Transactions.Transaction

在System.Transactions事务体系下，事务本身通过类型System.Transactions.Transaction类型表示，下面是Transaction的定义：

   1: [Serializable]   2: public class Transaction : IDisposable, ISerializable   3: {      4:     public event TransactionCompletedEventHandler TransactionCompleted;   5:        6:     public Transaction Clone();   7:     public DependentTransaction DependentClone(DependentCloneOption cloneOption);   8:        9:     public Enlistment EnlistDurable(Guid resourceManagerIdentifier, IEnlistmentNotification enlistmentNotification, EnlistmentOptions enlistmentOptions);  10:     public Enlistment EnlistDurable(Guid resourceManagerIdentifier, ISinglePhaseNotification singlePhaseNotification, EnlistmentOptions enlistmentOptions);      11:     public bool EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification promotableSinglePhaseNotification);    12:     public Enlistment EnlistVolatile(IEnlistmentNotification enlistmentNotification, EnlistmentOptions enlistmentOptions);  13:     public Enlistment EnlistVolatile(ISinglePhaseNotification singlePhaseNotification, EnlistmentOptions enlistmentOptions);  14:    15:     public void Rollback();  16:     public void Rollback(Exception e);  17:    18:     void ISerializable.GetObjectData(SerializationInfo serializationInfo, StreamingContext context);  19:    20:     public static Transaction Current { get; set; }     21:    22:     public IsolationLevel IsolationLevel { get; }  23:     public TransactionInformation TransactionInformation { get; }  24: }

1、Transaction是可序列化的

从上面的定义我们可以看到，Transaction类型（在没有特殊说明的情况下，以下的Transaction类型指的就是System.Transactions.Transaction）上面应用的SerializableAttribute特性，并且实现了ISerializable接口，意味着一个Transaction对象是可以被序列化的。Transaction的这一特性在WCF整个分布式事务的实现意义重大，原因很简单：要让事务能够控制整个服务操作，必须实现事务的传播，而传播的前提就是事务可被序列化。

2、如何登记事务参与者

在Transaction中，定义了五个EnlistXxx方法用于将涉及到的资源管理器登记到当前事务中。其中EnlistDurable和EnlistVolatile分别实现了对持久化资源管理器和易失资源管管理器的事务登记，而EnlistPromotableSinglePhase则针对的是可被提升的资源管理器（比如基于SQL Server 2005和SQL Server 2008）。

事务登记的目的是建立事务提交树，使得处于根节点的事务管理器能够在事务提交的时候能够沿着这棵树将相应的通知发送给所有的事务参与者。这种至上而下的通知机制依赖于具体采用事务提交协议，或者说某个资源要求参与到当前事务之中，必须满足基于协议需要的接收和处理相应通知的能力。System.Transactions将不同事务提交协议对参与者的要求定义在相应的接口中。其中IEnlistmentNotification和ISinglePhaseNotification分别是基于2PC和SPC（关于2PC和SPC，在上篇中有详细的介绍）。

如果我们需要为相应的资源开发能够参与到System.Transactions事务的资源管理器，需要事先实现IEnlistmentNotification接口，对基本的2PC协议提供支持。当满足SPC要求的时候，如果希望采用SPC优化协议，则需要实现ISinglePhaseNotification接口。如果希望像SQL Server 2005或者SQL Server 2008支持事务提升机制，则需要实现IPromotableSinglePhaseNotification接口。

3、环境事务（Ambient Transaction）

Transaction定义了一个类型为Transaction的Current静态属性（可读可写），表示当前的事务。作为当前事务的Transaction存储于当前线程的TLS（Thread Local Storage）中（实际上是定义在一个应用了ThreadStaticAttribute特性的静态字段上），所以仅对当前线程有效。如果进行异步调用，当前事务并不能自动事先跨线程传播，将异步操作纳入到当前事务，需要使用到另外一个事务：依赖事务。

这种基于当前线程的当前事务又称环境事务（Ambient Transaction），很多资源管理器都具有对环境事务的感知能力。也就是说，如果我们通过Current属性设置了环境事务，当对某个具有环境事务感知能力的资源管理器进行访问的时候，相应的资源管理器会自动登记到当前事务中来。我们将具有这种感知能力的资源管理器称为System.Transactions资源管理器。

4、事务标识

Transaction具有一个只读的TransactionInformation属性，表示事务一些基本的信息。属性的类型为TransactionInformation，定义如下：

   1: public class TransactionInformation   2: {     3:     public DateTime CreationTime { get; }       4:     public TransactionStatus Status { get; }   5:     6:     public string LocalIdentifier { get; }   7:     public Guid DistributedIdentifier { get; }   8: }

TransactionInformation的CreationTime和Status表示创建事务的时间和事务的当前状态。事务具有活动（Active）、提交（Committed）、中止（Aborted）和未决（In-Doubt）四种状态，通过TransactionStatus枚举表示。

   1: public enum TransactionStatus   2: {   3:     Active,   4:     Committed,   5:     Aborted,   6:     InDoubt   7: }

事务具有两个标识符，一个是本地标识，另一个是分布式标识，分别通过TransactionInformation的只读属性LocalIdentifier和DistributedIdentifier表示。本地标识由两部分组成：标识为本地应用程序域分配的轻量级事务管理器（LTM）的GUID和一个递增的整数（表示当前LMT管理的事务序号）。在下面的代码中，我们分别打印出三个新创建的可提交事务（CommittableTransaction，为Transaction的子类，我们后面会详细介绍）的本地标识。

   1: using System;   2: using System.Transactions;   3: class Proggram   4: {   5:     static void Main()   6:     {   7:         Console.WriteLine(new CommittableTransaction().TransactionInformation.LocalIdentifier);   8:         Console.WriteLine(new CommittableTransaction().TransactionInformation.LocalIdentifier);   9:         Console.WriteLine(new CommittableTransaction().TransactionInformation.LocalIdentifier);  10:     }  11: }

输出结果：

AC48F192-4410-45fe-AFDC-8A890A3F5634：1AC48F192-4410-45fe-AFDC-8A890A3F5634：2AC48F192-4410-45fe-AFDC-8A890A3F5634：3

一旦本地事务提升到基于DTC的分布式事务，系统会为之生成一个GUID作为其唯一标识。当事务跨边界执行的时候，分布式事务标识会随着事务一并被传播，所以在不同的执行上下文中，你会得到相同的GUID。分布式事务标识通过TransactionInformation的只读属性DistributedIdentifier表示，我经常在审核（Audit）中使用该标识。

对于上面Transaction的介绍，细心的读者可能会发现两个问题：Transaction并没有提供公有的构造函数，意味着我们不能直接通过new操作符创建Transaction对象；Transaction只有两个重载的Rollback方法，并没有Commit方法，意味着我们直接通过Transaction进行事务提交。

在一个分布式事务中，事务初始化和提交只能有相同的参与者担当。也就是说只有被最初开始的事务才能被提交，我们将这种能被初始化和提交的事务称作可提交事务（Committable Transaction）。随着分布式事务参与者逐个登记到事务之中，它们本地的事务实际上依赖着这个最初开始的事务，所以我们称这种事务为依赖事务（Dependent Transaction）。

二、可提交事务(CommittableTransaction)

只有可提交事务才能被直接初始化，对可提交事务的提交驱动着对整个分布式事务的提交。可提交事务通过CommittableTransaction类型表示。照例先来看看CommittableTransaction的定义：

   1: [Serializable]   2: public sealed class CommittableTransaction : Transaction, IAsyncResult   3: {      4:     public CommittableTransaction();   5:     public CommittableTransaction(TimeSpan timeout);   6:     public CommittableTransaction(TransactionOptions options);   7:     8:     public void Commit();   9:     public IAsyncResult BeginCommit(AsyncCallback asyncCallback, object asyncState);  10:     public void EndCommit(IAsyncResult asyncResult);  11:      12:     object IAsyncResult.AsyncState { get; }  13:     WaitHandle IAsyncResult.AsyncWaitHandle { get; }  14:     bool IAsyncResult.CompletedSynchronously { get; }  15:     bool IAsyncResult.IsCompleted { get; }  16: }

1、可提交事务的超时时限和隔离级别

CommittableTransaction直接继承自Transaction，提供了三个公有的构造函数。通过TimeSpan类型的timeout参数指定事务的超时实现，自被初始化那一刻开始算起，一旦超过了该时限，事务会被中止。通过TransactionOptions类型的options可以同时指定事务的超时时限和隔离级别。TransactionOptions是一个定义在System.Transactions命名空间下的结构（Struct），定义如下，两个属性Timeout和IsolationLevel分别代表事务的超时时限和隔离级别。

   1: [StructLayout(LayoutKind.Sequential)]   2: public struct TransactionOptions   3: {   4:     //其他成员   5:     public TimeSpan Timeout { get; set; }   6:     public IsolationLevel IsolationLevel { get; set; }   7: }

如果调用默认无参的构造函数来创建CommittableTransaction对象，意味着采用一个默认的超时时限。这个默认的时间是1分钟，不过可以它可以通过配置的方式进行指定。事务超时时限相关的参数定义在配置节中，下面的XML体现的是默认的配置。从该段配置我们可以看到，我们不但可以通过设置事务默认的超时时限，还可以通过设置最高可被允许的事务超时时限，默认为10分钟。在对这两项进行配置的时候，前者的时间必须小于后者，否则将用后者作为事务默认的超时时限。

   1: xml version="1.0" encoding="utf-8" ?>   2: <configuration>   3:   <system.transactions>   4:     <defaultSettings timeout="00:01:00"/>   5:     <machineSettings maxTimeout="00:10:00"/>   6:   system.transactions>   7: configuration>

作为事务ACID四大属性之一的隔离性（Isolation），确保事务操作的中间状态的可见性仅限于事务内部。隔离机制通过对访问的数据进行加锁，防止数据被事务的外部程序操作，从而确保了数据的一致性。但是隔离机制在另一方面又约束了对数据的并发操作，降低数据操作的整体性能。为了权衡着两个互相矛盾的两个方面，我们可以根据具体的情况选择相应的隔离级别。

在System.Transactions事务体系中，为事务提供了7种不同的隔离级别。这7中隔离级别分别通过System.Transactions.IsolationLevel的7个枚举项表示。

   1: public enum IsolationLevel   2: {   3:     Serializable,   4:     RepeatableRead,   5:     ReadCommitted,   6:     ReadUncommitted,   7:     Snapshot,   8:     Chaos,   9:     Unspecified  10: }

7个隔离级别之中，Serializable具有最高隔离级别，代表的是一种完全基于序列化（同步）的数据存取方式，这也是System.Transactions事务默认采用的隔离级别。按照隔离级别至高向低，7个不同的隔离级别代表的含义如下：

Serializable：可以在事务期间读取可变数据，但是不可以修改，也不可以添加任何新数据；
RepeatableRead：可以在事务期间读取可变数据，但是不可以修改。可以在事务期间添加新数据；
ReadCommitted：不可以在事务期间读取可变数据，但是可以修改它；
ReadUncommitted：可以在事务期间读取和修改可变数据；
Snapshot：可以读取可变数据。在事务修改数据之前，它验证在它最初读取数据之后另一个事务是否更改过这些数据。如果数据已被更新，则会引发错误。这样使事务可获取先前提交的数据值；
Chaos：无法覆盖隔离级别更高的事务中的挂起的更改；
Unspecified：正在使用与指定隔离级别不同的隔离级别，但是无法确定该级别。如果设置了此值，则会引发异常。

2、事务的提交

CommittableTransaction提供了同步（通过Commit方法）和异步（通过BeginCommit|EndCommit方法组合）对事务的提交。此外CommittableTransaction还是实现了IAsyncResult这么一个接口，如果采用异步的方式调用BeginCommit方法提交事务，方法返回的IAsyncResult对象的各属性值会反映在CommittableTransaction同名属性上面。

前面我们提到了环境事务已经System.Transactions资源管理器对环境事务的自动感知能力。当创建了CommittableTransaction对象的时候，被创建的事务并不会自动作为环境事务，你需要手工将其指定到Transaction的静态Current属性中。接下来，我们将通过一个简单的例子演示如果通过CommittableTransaction实现一个分布式事务。

3、实例演示：通过CommittableTransaction实现分布式事务

在这个实例演示中，我们沿用介绍事务显式控制时使用到的银行转帐的场景，并且直接使用第一篇中创建的帐户表（T_ACCOUNT）。一个完整的转帐操作本质上有两个子操作完成，提取和存储，即从一个帐户中提取相应的金额存入另一个帐户。为了完成这两个操作，我写了如下两个存储过程：P_WITHDRAW和P_DEPOSIT。

P_WITHDRAW：

   1: CREATE Procedure P_WITHDRAW   2:     (   3:         @id        VARCHAR(50),   4:         @amount FLOAT   5:     )   6: AS   7: IF NOT EXISTS(SELECT * FROM [dbo].[T_ACCOUNT] WHERE ID = @id)   8:     BEGIN   9:         RAISERROR ('帐户ID不存在',16,1)  10:         RETURN  11:     END      12: IF NOT EXISTS(SELECT * FROM [dbo].[T_ACCOUNT] WHERE ID = @id AND BALANCE > @amount)  13:     BEGIN  14:         RAISERROR ('余额不足',16,1)  15:         RETURN  16:     END  17:       18: UPDATE     [dbo].[T_ACCOUNT] SET Balance = Balance - @amount WHERE Id = @id  19: GO

P_DEPOSIT：

   1: CREATE Procedure P_DEPOSIT   2:     (   3:         @id        VARCHAR(50),   4:         @amount FLOAT   5:     )   6: AS   7: IF NOT EXISTS(SELECT * FROM [dbo].[T_ACCOUNT] WHERE Id = @id)   8:     BEGIN   9:         RAISERROR ('帐户ID不存在',16,1)  10:     END  11: UPDATE     [dbo].[T_ACCOUNT] SET Balance = Balance + @amount WHERE Id = @id  12: GO

为了确定是否成功转帐，我们需要提取相应帐户的当前余额，我们相应操作实现在下面一个存储过程中。

   1: CREATE Procedure P_GET_BALANCE_BY_ID   2:     (   3:         @id VARCHAR(50)   4:     )   5: AS   6: IF NOT EXISTS(SELECT * FROM [dbo].[T_ACCOUNT] WHERE Id = @id)   7:     BEGIN   8:         RAISERROR ('帐户ID不存在',16,1)   9:     END  10: SELECT BALANCE FROM [dbo].[T_ACCOUNT] WHERE Id = @id  11: GO

为了执行存储过程的方便，我写了一个简单的工具类DbAccessUtil。ExecuteNonQuery和ExecuteScalar的作用于DbCommand同名方法相同。使用DbAccessUtil的这两个方法，只需要以字符串和字典的方式传入存储过程名称和参数即可。由于篇幅所限，关于具有实现不再多做介绍了，又兴趣的读者，可以参考《WCF技术剖析（卷1）》的最后一章，里面的DbHelper提供了相似的实现。

   1: public static class DbAccessUtil   2: {   3:     public static int ExecuteNonQuery(string procedureName, IDictionary<string, object> parameters);   4:     public static T ExecuteScalar(string procedureName, IDictionary<string, object> parameters);   5: }

借助于DbAccessUtil提供的辅助方法，我们定义两个方法Withdraw和Deposit分别实现提取和存储的操作,已近获取某个帐户当前余额。

   1: static void Withdraw(string accountId, double amount)   2: {   3:     Dictionary<string, object> parameters = new Dictionary<string, object>();   4:     parameters.Add("id", accountId);   5:     parameters.Add("amount", amount);   6:     DbAccessUtil.ExecuteNonQuery("P_DEPOSIT", parameters);   7: }    8: static void Deposite(string accountId, double amount)   9: {  10:     Dictionary<string, object> parameters = new Dictionary<string, object>();  11:     parameters.Add("id", accountId);  12:     parameters.Add("amount", amount);  13:     DbAccessUtil.ExecuteNonQuery("P_DEPOSIT", parameters);  14: }  15: private static double GetBalance(string accountId)  16: {  17:     Dictionary<string, object> parameters = new Dictionary<string, object>();  18:     parameters.Add("id", accountId);  19:     return DbAccessUtil.ExecuteScalar<double>("P_GET_BALANCE_BY_ID", parameters);  20: }

现在假设帐户表中有一个帐号，它们的ID分别为Foo，余额为5000。下面是没有采用事务机制的转帐实现（注意：需要转入的帐户不存在）。

   1: using System;   2: using System.Collections.Generic;   3: namespace Artech.TransactionDemo   4: {   5:     class Program   6:     {   7:         static void Main(string[] args)   8:         {   9:             string accountFoo = "Foo";  10:             string nonExistentAccount = Guid.NewGuid().ToString();              11:             //输出转帐之前的余额  12:             Console.WriteLine("帐户\"{0}\"的当前余额为：￥{1}", accountFoo, GetBalance(accountFoo));  13:             //开始转帐      14:             try  15:             {  16:                 Transfer(accountFoo, nonExistentAccount, 1000);  17:             }  18:             catch (Exception ex)  19:             {  20:                 Console.WriteLine("转帐失败，错误信息：{0}", ex.Message);  21:             }  22:             //输出转帐后的余额  23:             Console.WriteLine("帐户\"{0}\"的当前余额为：￥{1}", accountFoo, GetBalance(accountFoo));  24:         }  25:    26:         private static void Transfer(string accountFrom, string accountTo, double amount)  27:         {  28:             Withdraw(accountFrom, amount);  29:             Deposite(accountTo, amount);  30:         }  31:     }  32: }

输出结果：

帐户"Foo"的当前余额为：￥5000转帐失败，错误信息：帐户ID不存在帐户"Foo"的当前余额为：￥4000

由于没有采用事务，在转入帐户根本不存在情况下，款项依然被转出帐户提取出来。现在我们通过CommittableTransaction将整个转帐操作纳入同一个事务中，只需要将Transfer方法进行如下的改写：

   1: private static void Transfer(string accountFrom, string accountTo, double amount)   2: {   3:     Transaction originalTransaction = Transaction.Current;   4:     CommittableTransaction transaction = new CommittableTransaction();   5:     try   6:     {   7:         Transaction.Current = transaction;   8:         Withdraw(accountFrom, amount);   9:         Deposite(accountTo, amount);  10:         transaction.Commit();  11:     }  12:     catch (Exception ex)  13:     {  14:         transaction.Rollback(ex);  15:         throw;  16:     }  17:     finally  18:     {  19:         Transaction.Current = originalTransaction;  20:         transaction.Dispose();  21:     }  22: }

输出结果（将余额恢复成5000）：

帐户"Foo"的当前余额为：￥5000转帐失败，错误信息：帐户ID不存在帐户"Foo"的当前余额为：￥5000

下一篇中我们将重点介绍DependentTransaction和TransactionScope。

评论: 4　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

谈谈分布式事务之二：基于DTC的分布式事务管理模型[下篇]

Artech — Wed, 27 Jan 2010 14:41:00 GMT

阅读: 1285 评论: 10 作者: Artech 发表于 2010-01-27 22:41 原文链接

[续上篇]当基于LTM或者KTM的事务提升到基于DTC的分布式事务后，DTC成为了本机所有事务型资源管理器的管理者；此外，当一个事务型操作超出了本机的范围，出现了跨机器的调用后，本机的DTC需要于被调用者所在机器的DTC进行协助。上级对下级（包括本机DTC对本机所有资源管理器，以及上下级DTC）的管理得前提是下级在上级那里登记，即事务登记（Transaction Enlist）。所有事务参与者，包括所有资源管理器和事务管理器（即DTC）在进行了事务等级完成之后形成了一个树形的层级结构，该结构的形成是后续的事务提供成为可能，因此我们将其称之为事务提交树（Transaction Commit Tree）。

一、事务登记（Transaction Enlisting）和事务提交树（Transaction Commit Tree）

事务登记的目的在于建立起事务参与者（只要指资源管理器和事务管理器DTC）之间的关系，促进相互之间的协作。我们先来看看整个事务登记是如何进行的，整个事务登记流程大致如图1所示。

图1 事务登记的流程

图1所示的事务涉及到部署与两台机器（Machine A和Machine B）上两个服务之间的交互，事务由Service初始化，在调用Service2的时候被传播到Machine B，从而将分布于两台机器的资源管理器纳入到同一个事务之中。接下来，我们对整个流程进行详细介绍。

首先，Service A开始一个新的事务，并将其最为当前执行上下文的环境事务（Ambient Transaction）。当Service A调用本机的资源管理器的时候，会将该资源管理器纳入到本事务之中（对于我们后续要介绍的System.Transactions事务，像SQL Server、Oracle以及MSMQ等资源管理器都能够自动感知到当前的环境事务）。此时，资源管理器（RM）向本机的DTC进行事务登记，从此DTC和资源管理器之间建立起了上下级关系。

当Service A在调用Service B的时候，会将当前事务的一些信息，比如分布式事务的ID以及关于本机DTC相关信息，封装在消息中（一般是SOAP报头）向对方传递。当Service B接受到服务调用请求消息，会将事务相关的信息提取出来在本地重建事务，并将其作为当前的环境事务，该事务和原事务具有相同的ID。同时，根据得到的关于Machine A的DTC相关信息，让本机的DTC对Machine A的DTC进行事务登记，进而使两台机器的DTC确立了上下级关系。

和Service A访问本机的资源管理器一样，Machine B的资源管理器被Service B调用并被纳入当前事务的时候，会向本机DTC进行事务登记。

当上面所述的事务登记流程结束后，参与整个分布式事务的DTC和资源管理器形成了如图2所示的树形层次结构，由于该结构的构建主要是为了后面对整个事务的提交服务的，所以我们一般将其称为事务提交树（Transaction Commit Tree）。事务提交树的根为事务初始化服务所在机器的DTC，在整个事务提交过程中，它是总的协调者，又被称为全局提交协调器（GCC：Global Commit Coordinator ）。资源管理器充当事务提交树的叶子节点，它们的父节点为本机的DTC。分布于不同机器的DTC按照事务传播的路径形成上下级关系。

图2 事务提交树

事务提交树的构建使得对分布式事务的提交成为可能，分布式事务的提交采用两阶段协议实现，接下来我们详细介绍基于两阶段提交协议的事务提交机制。

二、基于两阶段提交（2PC：Two-Phase Commit）协议的事务提交机制

注：在事务初始化服务决定提交事务之前，任何一个参与者均可以中止（Abort）该事务，任何一个参与者对事务的中止都将导致整个分布式事务的回滚。

1、第一阶段（Phase I）：准备（Prepare）阶段

在第一个阶段，作为根节点的DTC沿着事务提交树的路径，向所有事务的参与者发起请求，要求它们对本地事务的结果进行投票。被请求的参与者将本地事务结果返回给自己的上级，对于资源管理器，自己的上级就是本机的DTC；如果自己本身就是DTC，那么自己得上级就是位于事务提交树父节点的DTC。根据具体事务操作执行的情况，参与者投票的类型包括如下三种：

就绪（Prepared）：参与者同意对事务的提交，并承诺在接收到真正的提交请求后完成本地的提交任务；
只读（Read-only）：参与者同意对事务的提交，但是不希望接收真正的事务提交请求；
中止（Aborted）：参与者要求中止事务。

对于一个非根节点DTC来说，当它从父节点接收到标准的“准备”请求后，会立即将该请求沿着事务提交树发送给自己的下级（本机的资源管理器和下级DTC），然后根据从下级接收的所有投票结果，计算出自己投票的结果。具体的算法是：如果所有的投票结果都是“就绪”和“只读”，对应的结果是“提交”，反之，如果任何一个投票结果是“中止”，则最终的结果就是“中止”，换句话说，任何一个事务参与者具有一票否决权最后。最后，DTC将计算出来的投票结果反馈给自己的上级。

当根节点DTC接收到隶属于自己的所有资源管理器和下级DTC的投票结果后，采用于上面一样的算法决定整个分布式事务的最终结果。当根节点DTC决定了事务最终的结果后，整个提交过程进入第二阶段。

注：我们可以设置事务的超时时限，如果根节点DTC在该时限内没有介绍到所有参与者的投票请求，会对整个分布式事务做出回滚的决定。

2、第二阶段（Phase II）：提交（Commit）或中止（Abort）

作为事务提交树根节点的DTC根据最终的事务结果，对整个事务进行最终的提交或者中止操作。同样是沿着事务提交树的路径，提交或者中止请求被广播出去。相应的资源管理器根据从本机DTC获得的请求，实施最终的提交或者恢复操作。当事务参与者完成了各自就的任务后，类似于第一个阶段的投票，会讲执行的结果沿着事务提交树逆向回馈给作为根节点的DTC。

根节点DTC只有接收到所有事务参与者的基于各自事务处理的回复，才能确保整个事务被成功提交或者回滚。那么如果事务的参与者完成了第一阶段的投票，网络断开，那将如何呢？这就涉及到对未决（In-Doubt）事务的处理。

3、未决（In-Doubt）事务的处理

对于某个分布式事务的参与者（DTC或者资源管理器）来说，在第一阶段向上级（事务提交树的父节点）投票表明提交就绪（Prepared）之后，直到它接收到根节点DTC最终的提交或者回滚的请求，它并不知晓本地事务的结果。在这期间，如果出现当机并重启，本地的事务处于一种“未决（In-Doubt）”状态。未决事务仅仅出现在非根节点DTC所在的机器。分布式事务采用如下的机制处理未决事务。

当重启后，对于本机的所有未决事务，DTC会向上级DTC发送查询请求，获取每一个事务最终的结果（提交还是中止）。如果上级也不能决定事务的结果，那么请求会沿着事务提交树不断向上（沿着根的方向）发送，直到得到一个明确的答复（不管怎样，位于根节点的全局提交协调器总是清楚事务的结果的）。

此外，当下级DTC向自己发送相同的查询请求的时候，该DTC会讲获取到的结果回复给它们。如果未决事务存在的时间太长，系统管理者可以强制提交或者中止该事务。

4、单阶段提交（SPC: Single-Phase Commit）优化

对于事务最终结果（提交或者中止）的决策者来说，如果它具有了不止一个下级，那么采用基于投票机制的两阶段提交协议唯一选择。但是如果仅仅具有一个唯一的下级呢，这种投票机制就没有必要了。在这种情况下，根节点DTC采用一种优化的协议来完成整个事务的提交，我们称之为单阶段提交（SPC：Single-Phase Commit）。

顾名思义，2PC意味着整个事务提交分成两个阶段，SPC则表示将其所短为一个阶段。整个流程很简单，如果根节点DTC仅仅只有一个登记的事务参与者（本机资源管理器或者下级DTC），而不管这个下级自身具有几个下级，它不会像2PC一样先向下级发送“准备”请求，而是直接发送提交请求，我们将这个请求成为单阶段提交（SPC）请求。接收到SPC请求的参与者，如果是资源管理器，则直接提交本地事务，并将最终结果（成功提交或者失败中止）反馈给这个跟节点DTC。

如果SPC请求的接收者是DTC，那么会根据隶属于自己的下级的数量选择相应的提交策略。具体做法和根节点DTC提交策略的选择方式一样：如果自己具有唯一一个下级，则采用SPC，反之采用2PC。

也就是说，不仅仅是根节点DTC可以选择SPC提交事务，任何具有单一下级的DTC均可以采用SPC。但是，非根节点DTC只有在接收到SPC请求的情况下，才能选择通过SPC提交事务。如图3给出了两颗事务提交树（图中忽略掉资源管理器，每个节点代表DTC），对于左边的树，因为根节点A和下级B均只有一个唯一的下级，所以A和B均采用SPC，C具有两个下级，则采用2PC。而对于右边的树，因为根节点本身具有两个下级，决定了所有的节点均采用2PC，即使是对于只有一个下级的B和C。

图3 DTC对SPC和2PC的选择

我们我们介绍整个Windows平台基于DTC的分布式事务管理模型，接下来的一篇中，我将会详细介绍基于System.Transactions事务的编程。

评论: 10　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

谈谈分布式事务之二：基于DTC的分布式事务管理模型[上篇]

Artech — Wed, 27 Jan 2010 13:42:00 GMT

阅读: 1287 评论: 5 作者: Artech 发表于 2010-01-27 21:42 原文链接

对于所有的事务参与者，按照各自在整个事务生命周期各个阶段所承担的职能，大致扮演着如下三种角色：

应用（Application）、服务（Service）或者组件（Component）：代表用户程序，或者是承载着某功能的服务（Service）或者组件（Component）；
资源管理器（RM：Resource Manager）:代表用于管理具体事务型资源的软件程序，比如数据库或者队列（MSMQ）等；
事务管理器（TM： Transaction Manager）:代表管理整个事务的中间件程序，为应用和资源管理器提供基本的事务控制服务。

一、应用（Application）、服务（Service）和组件（Component）

事务最终为用户程序、服务和组件服务的，后者利用了事务这种特殊的机制将一组相关的操作作为一个不可分割的整体来执行，从而确保了数据的一致性。在整个模型中，应用（服务或者应用，为了叙述简练，后续部分关于应用、服务和组件都简称为应用）主要负责如下一些事务相关的任务：

开始事务：事务开始的驱动者总是应用，但是并不是所有的应用都会开始一个新的事务，只有最初的应用才才是事务的开启者；
事务的奉送（Marshaling）和传播（Propagation）：将应用的本地事务封送、传播给另一个应用或者资源管理器；
提交事务：事务的开启者同时也是事务最终的提交者，当事务相关的操作顺利完成后，最初开启事务的应用会提交该事务。

二、资源管理器（RM：Resource Manager）

在事务控制模型中，不论是应用还是资源管理器都不是直接地访问具体的事务型资源，而是通过一个中介间接地对目标资源进行操作，这个中介就是资源管理器。按照目标资源是否可被持久化，可以将相应的资源管理器分为如下两类：

持久化资源管理器（Durable Resource Manager）：用于管理持久化资源，比如数据库和MSMQ，当事务回滚得时候，具有可恢复性（Recovery）；
易失资源管理器（Volatile Resource Manager）：用于管理像内存数据这样的不会被持久化的易失资源，易失资源不具有可以恢复性。

在后面介绍的实现分布式事务的两阶段提交（2PC： Two-Phase Commit）协议中，对于这两种不同的资源管理器，采用不同的登记（Enlist）方式。总的来说，资源管理器在整个事务模型中主要承担如下几种职能：

帮助应用实现对目标资源的操作；
注册到相应的事务管理器，以便事务回滚得时候可以从事务管理器中接收到恢复请求，实现对数据的恢复；
向相应的事务管理器报告本地事务的结果；

三、事务管理器(Transaction Manager)

事务管理器是整个事务控制模型的核心和枢纽，是它控制着事务的所有参与者，协调整个事务从开始到完成的所有相关处理流程。事务管理器为应用和资源管理器提供一系列核心的事务性的服务，实现事务的开始、提交和回滚。Windows提供了三种不同的事务管理器，我们现在对它们进行逐个介绍。

1、轻量级事务管理器（LTM: Lightweight Transaction Manager）

正如其名称隐含的意思,轻量级事务管理器（以下简称LTM）具有最小的负载,是性能最高的事务管理器。LTM的作用范围仅限于开启事务的应用程序域（AppDomain）中，并且登记到事务中的持久化资源（Durable Resource）数量不能超过一个。

一般地，被开启的事务就由LTM管理，如果事务涉及到跨应用程序域的操作，当前的事务回被奉送、传播到另一个执行上下文中，此时事务将脱离LTM的管辖。此外，基于LTM的事务中可以同时登记（Enlist）多个易失型资源（Volatile），但是仅仅允许登记唯一一个持久化资源。当第二个持久化资源被登记到当前事务中，该事务也将脱离LTM的管辖。

并不是所有的持久化资源都可以登记到LTM，实际上到目前为止，能够登记到LTM这么一个高性能的事务管理器的事务型资源仅仅限于SQL Server 2005和SQL Server 2008，即使是同属于Windows平台下SQL Server 2000和MSMQ均不支持LTM，更不用说Oracle和DB2。我们希望微软能够和其他的厂商进行合作，让第三方开发的事务型资源也能利用LTM性能的优势。

2、内核事务管理器（KTM：Kernel transaction Manager）

内核事务管理器（以下简称KTM）在Windows Vista中被引入，并被用于后续的Windows Server 2008和Windows 7。引入KTM的主要的目的在于实现将文件管理和注册表管理纳入事务的范畴。借助于KTM，我们可以以事务的方式操作NTFS文件系统下的文件资源，以及注册表资源。我们将支持事务的文件系统和注册表成为事务型的文件系统（TxF）和事务型注册表（TxR）。

之所以被称为内核事务管理器，使因为基于KTM的事务控制引擎运行在内核模式（Kernel Mode）,而不是用户模式（User Mode）下。和LTM一样，KTM对易失型事务资源没有限制，却至于单一的持久化事务资源被涉及。

从上面的介绍我们不难看出，无论是LTM还是KTM，其管辖范围仅限于本地事务，对于分布式事务却无能为力。分布式事务依赖于一个更为强大的事务管理器，就是我们接下来着重介绍的分布式事务协调器。

3、分布式事务协调器（DTC：Distributed Transaction Coordinator）

对于分布式事务协调器，我们大都简称为DTC，或者MS DTC，以下我们直接简称DTC。DTC用于管理跨边界（跨应用程序域、进程、机器以至跨网络）执行的分布式事务，它采用相应的事务管理协议，比如Ole-Tx和WS-Atomic Transaction（WS-AT），协调一个分布式事务中的所有参与者。

每一台机器上具有一个唯一的DTC，事务涉及的承载于某台机器的所有事务型资源均由当前机器的DTC管理。当事务跨越多台机器时，它们各自的DTC需要按照相应的协议相互协作，实现对整个事务的一致性管理。

4、事务提升（Transaction Promotion）

以上我们介绍了三种不同的事务管理器类型，从功能上讲，DTC能够协调、管理一个分布式事务涉及的所有事务型资源，而不管具体的资源分布于何处。但是，由于其事务控制的复杂性（一般采用两阶段提交协议）并需要进行跨进程、跨机器甚至跨网络通信，在性能上无疑是最差的。所以，我们不可能在任何事务场景中都采用DTC，所谓“牛刀虽好、不便杀鸡”，我们应该根据事务控制的需要选择性能最高的事务管理器。

但是，事务是一个动态执行的操作序列，系统不可能预知完整执行整个事务所有操作后的资源登记情况，所以不可以预先为其指定一个为相应事务多身定制的事务管理器。相反地，只能在事务具体的执行过程中，动态地选择最适合当前事务执行情况的事务管理器。Windows采用事务提升的机制进行事务管理器的选择。

一般情况下，事务开始的时候，LTM默认被作为当前的事务管理器。随着事务操作的逐步执行，如何该事务涉及到对某个内核事务资源的访问，那么自动提升到基于KTM的事务。无论是基于LTM还是KTM的事务，在当出现如下两种情况的时候，会向基于DTC事务提升：

事务操作涉及到对多个LTM资源的访问或者访问的资源不被LTM支持：比如说，当事务应用开启两个基于SQL Server 2008（LTM事务型资源）的连接进行数据存取；或者，访问开启一个基于Oracle（非LTM事务型资源）的连接进行数据存取；
当前事务被跨应用程序域封送（Marshaling）：比如说，放一个服务调用另一个服务的时候，将当前事务进行序列化以实现向被调用服务方传播。

由于WCF的事务体系解决的是事务在服务之间的流转，以及对服务操作直接或者间接访问的所有事务型资源的协作，这样的事务时通过基于DTC的分布式事务实现的。接下来，我们就来简单讨论一下《基于DTC的分布式事务实现的》。

评论: 5　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

谈谈分布式事务之一：SOA需要怎样的事务控制方式

Artech — Tue, 26 Jan 2010 14:57:00 GMT

阅读: 1823 评论: 33 作者: Artech 发表于 2010-01-26 22:57 原文链接

一、什么是事务（Transaction）

事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。事务具有如下四个属性，根据其首字母，我们一般将其称为事务的ACID四大属性：

原子性（Atomicity）：“原子”这个词的本义就是不可分割的意思，事务的原子性的含义是：一个事务的所有操作被捆绑成一个整体，所有的操作要么全部执行，要么都不执行；
一致性（Consistence）：事务的原子性确保一个事务不会破环数据的一致性，如果事务成功提交，数据的状态是组成事务的所有操作按照事先编排的方式执行的结果，数据状态具有一致性；如果事务任何一个中间步骤出错，整个事务回滚并将数据回复到原来的状态，数据状态仍然具有一致性。所以，事务只会将数据状态从一个一致性状态转换到另一个一致性状态；
隔离性（Isolation）：从事务的外部来看，事务的一致性实现了数据在两个一致性状态之间的转换，但是从事务内部来看，组成事务的各个操作是按照一定的逻辑顺序执行的，所以数据具有位于两个一致性状态的“中间状态”。但是，这种中间状态被隔离于事务内部，对于事务外部是不可见的；
持久性（Durability）：持久性的意思是一旦成功提交，基于持久化资源（比如数据库）的数据将会被持久化，对数据的改变是永久性的。

事务最初来源于数据库管理系统（DBMS），反映的是对存储于数据库中的数据操作。除了主流的关系型数据库管理系统，比如SQL Server，Oracle和DB2等提供对事务的支持，基于事务的数据操作方式也可以应用到其他一些数据存储资源，比如MSMQ。自Windows Vista开始将文件系统（NTFS）以至于注册表纳入了事务型资源（Transactional Resource）的范畴。

二、事务的显式控制

虽然事务型资源家族成员越来越多，但是不可否认的是，数据库还是我们使用频率最高的事务型资源。对于稍微有一定经验的开发人员，应该都在存储过程（Stored Procedure）中编写过基于事务的SQL，或者编写过基于ADO.NET事务的代码，对事务的进一步介绍就从这里说起。

1、SQL中的事务处理

无论是基于SQL Server的T-SQL，抑或是基于Oracle的PL-SQL都对事务提供了原生的支持，有意思的是T-SQL中的T本身指的就是事务（Transaction）。以T-SQL为例，我们可以通过如下三个SQL语句实现事务的启动、提交与回滚：

BEGIN TRANSACTION: 开始一个事务；
COMMIT TRANSACTION：提交所有位于BEGIN TRANSACTION和COMMIT TRANSACTION之间的操作；
ROLLBACK TRANSACTION：回滚所有位于BEGIN TRANSACTION和COMMIT TRANSACTION之间的操作。

我们举一个很典型的基于事务型操作的例子：银行转帐，而且这个例子将会贯穿于本章的始终。为此，我们先创建一个最为简单的用于存储帐户的数据表：T_ACCOUNT,整个表近仅仅包括三个字段（ID、NAME和BALANCE），它们分别代表银行帐号的ID、名称和余额。创建该表的T-SQL如下：

   1: CREATE TABLE [dbo].[T_ACCOUNT](   2:     [ID]        VARCHAR(50)     PRIMARY KEY,   3:     [NAME]      NVARCHAR(50)    NOT NULL,   4:     [BALANCE]   FLOAT           NOT NULL)   5: GO

银行转帐是一个简单的复合型操作，由两个基本的操作构成：存储和提取，即从一个帐户中提取相应金额出入另一个帐户。对数据完整性的要求是我们必须将这两个单一的操作纳入同一个事务。如果我们通过一个存储过程来完成整个转帐的流程，具体的SQL应该采用下面的写法：

   1: CREATE Procedure P_TRANSFER   2:     (   3:         @fromAccount    VARCHAR(50),   4:         @toAccount      VARCHAR(50),   5:         @amount         FLOAT   6:     )   7: AS   8:     9: --确保帐户存在性  10: IF NOT EXISTS(SELECT * FROM [dbo].[T_ACCOUNT] WHERE ID = @fromAccount)  11:     BEGIN  12:         RAISERROR ('AccountNotExists',16,1)   13:         RETURN  14:     END      15: IF NOT EXISTS(SELECT * FROM [dbo].[T_ACCOUNT] WHERE ID = @toAccount)  16:     BEGIN  17:         RAISERROR ('AccountNotExists',16,1)   18:         RETURN  19:     END  20: --确保余额充足性  21: IF NOT EXISTS(SELECT * FROM [dbo].[T_ACCOUNT] WHERE ID = @fromAccount AND BALANCE >= @amount)  22:     BEGIN  23:         RAISERROR ('LackofBalance',16,1)  24:         RETURN  25:     END  26: --转帐  27: BEGIN TRANSACTION  28:     UPDATE     [dbo].[T_ACCOUNT] SET BALANCE = BALANCE - @amount WHERE ID = @fromAccount  29:     IF @@ERROR <> 0   30:         BEGIN  31:             ROLLBACK TRANSACTION  32:         END  33:     UPDATE     [dbo].[T_ACCOUNT] SET BALANCE = BALANCE + @amount WHERE ID = @toAccount  34:     IF @@ERROR <> 0   35:         BEGIN  36:             ROLLBACK TRANSACTION  37:         END  38: COMMIT TRANSACTION  39: GO

2、 ADO.NET事务控制

无论是T-SQL，还是PL-SQL，抑或是其他数据库管理系统对标准SQL的扩展，不仅仅是提供基于标准SQL的DDL（Data Definition Language）和DML（Data Manipulation Language），还提供了对函数、存储过程和流程控制的支持。SQL Server至2005起，甚至实现了与CLR（Common Language Runtime）的集成，使开发人员可以使用任何一种.NET语言编写编写函数或者存储过程。毫无夸张地说，你可以通过SQL实现任何业务逻辑。

但是，在大多数情况我们并不这么做，我们更多地还是将SQL作为最基本的数据操作语言在使用。对于.NET开发者来说，我们还是习惯将复杂的逻辑和流程控制实现在通过C#或者VB.NET这样的面相对象编程语言编写的程序中。究其原因，我觉得主要有两点：

面相对象的语言更能容易地实现复杂的逻辑：较之SQL这种基于集合记录的语言，面相对象的语言更加接近于我们真实的世界，通过面相对象的方式模拟具体的逻辑更加贴近于人类的思维方式。此外，通过面相对语言本身的一些特性，我们可以更加容易地应用各种设计模式和思想；
将太多逻辑运算的执行放在数据库中不利于应用的扩展：从部属的角度来讲，数据操作运算负载到具体的服务器中，以一个典型的分布式Web应用为例，Web服务器（承载Web应用）、应用服务器（承载各种服务）和数据库服务器均可以承载最终对逻辑的运算。但是，从可扩展性（或者可伸缩性）上考虑，将主要的计算放在前两者比放在数据库更具优势。如果我们将密集的运算（这种运算需要占用更多的CPU时间和内存）迁移到Web服务器或者应用服务器，我们可以通过负载均衡（Load Balance）将其分流到多台服务器上面，这个服务器机群可以根据负载情况进行动态地配置。但是，数据库服务器对负载均衡的支持就不那么容易。

正因为如此，对于事务的控制，较之采用SQL的实现方式，我们使用得最多的还是采用基于面相对象语言编程的方式。对于.NET开发人员，我们可以直接利用ADO.NET将基于单个数据库连接的多个操作纳入同一个事务之中。同样以上面的银行转帐事务为例，这次我们将整个转帐作为一个服务（BankingService）的一个操作（Transfer）。下面的代码通过一种与具体数据库类型无关的ADO.NET编程模式实现了整个银行转帐操作，最终的转帐通过调用一个存储过程实现：

   1: public class BankingService : IBankingService   2: {   3:     //其他操作   4:     public void Transfer(string fromAccountId, string toAccountId, double amount)   5:     {   6:         string connectionStringName = "BankingDb";   7:         string connectionString = ConfigurationManager.ConnectionStrings[connectionStringName].ConnectionString;   8:         string providerName = ConfigurationManager.ConnectionStrings[connectionStringName].ProviderName;   9:         DbProviderFactory dbProviderFactory = DbProviderFactories.GetFactory(providerName);  10:         using (DbConnection connection = dbProviderFactory.CreateConnection())  11:         {  12:             connection.ConnectionString = connectionString;  13:             DbCommand command = connection.CreateCommand();  14:             command.CommandText = "P_TRANSFER";  15:             command.CommandType = CommandType.StoredProcedure;  16:    17:             DbParameter parameter = dbProviderFactory.CreateParameter();  18:             parameter.ParameterName = BuildParameterName("fromAccount");  19:             parameter.Value = fromAccountId;  20:             command.Parameters.Add(parameter);  21:    22:             parameter = dbProviderFactory.CreateParameter();  23:             parameter.ParameterName = BuildParameterName("toAccount");  24:             parameter.Value = toAccountId;  25:             command.Parameters.Add(parameter);  26:    27:             parameter = dbProviderFactory.CreateParameter();  28:             parameter.ParameterName = BuildParameterName("amount");  29:             parameter.Value = amount;  30:             command.Parameters.Add(parameter);  31:    32:             connection.Open();  33:             using (DbTransaction transaction = connection.BeginTransaction())  34:             {  35:                 command.Transaction = transaction;  36:                 try  37:                 {  38:                     command.ExecuteNonQuery();  39:                     transaction.Commit();  40:                 }  41:                 catch  42:                 {  43:                     transaction.Rollback();  44:                     throw;  45:                 }  46:             }  47:         }  48:     }  49: }

注：为了使上面一段代码能够同时用于不同的数据库类型，比如SQL Server和Oracle，我通过提取连接字符串配置中的数据库提供者（DbProvider）名称，借此创建相应的DbProviderFactory对象。所有ADO.NET对象，包括DbConnection、DbCommand、DbParameter以及DbTransaction均通过DbProviderFactory创建，所以并不和具体的数据库类型绑定在一起。此外，基于不同数据库类型的存储过程的参数命名各不相同，比如 SQL Server的参数会添加”@”前缀，为此我将对参数名称的解析实现在一个单独的方法（BuildParameterName）之中。

3、事务的显式控制限定于对单一资源的访问

通过在SQL中进行事务的控制，只能将基于某一段SQL语句的操作纳入到一个单一的事务中；如果采用基于ADO.NET的数据控制，被纳入到同一个事务的操作仅仅限于某个数据库连接。换句话说，上面介绍的这两种对事务的显式控制仅仅限于对单一的本地资源的控制。

我们将事务的概念引入服务，倘若我们将一个单一的服务操作作为一个事务，如果采用上述的显式事务控制的方式，那么整个服务操作只能涉及一个单一的事务资源。服务于存取的资源关系如图1所以。

图1 本地事务对单一资源的控制

上述的这种基于某个服务单一本地资源的访问的事务，被称为本地事务（Local Transaction），在一个基于SOA分布式应用环境下，我们需要的同时能将多个资源、多个服务进行统一协作的分布式事务（Distributed Transaction）。接下来，我们来介绍几种典型的分布式事务应用的场景。

三、分布式事务（Distributed Transaction）应用场景

对于一个分布式事务（Distributed Transaction）来讲，事务的参与者分布于网络环境中的不同的节点。也就是说，我们可以将多个事务资源纳入到一个单一的事务之中，并且这些事务资源可以分布到不同的机器上。这些承载分布式资源的机器可能是出于同一个网络中，也可能处于不同的网络中。甚至说，某个事务资源本质上就是一个通过HTTP访问的单纯的Internet资源。

站在SOA的角度来看分布式事务，意味着将服务的某个服务操作视为一个单一的事务。该服务操作可能会访问不止一个事务资源（比如访问两个不同的数据库服务器），也可能调用另一个服务。下面介绍了三个典型的分布式事务应用场景，先从最简单的说起。

1、将对多个资源的访问纳入同一事务

第一个分布式事务应用场景最简单，即一个服务操作并不会调用另一个服务，但是服务操作涉及到对多个事务资源的访问。当一个服务操作访问不同的数据库服务器，比如两台SQL Server，或者一台SQL Server和一台Oracle Server；当一个服务操作访问的是相同数据库，但是相应的数据库访问时基于不同的数据连接；当一个服务操作处理访问数据库资源，还需要访问其他份数据库的事务资源，就需要采用分布式事务来对所有的事务参与者进行协作了。图2反映了这样的分布式应用场景。

图2 单一服务对多个事务资源的访问

2、将对各个服务的调用纳入同一事务

对于上面介绍的分布式应用场景，尽管一个服务操作会访问多个事务资源，但是毕竟整个事务还是控制在单一的服务内部。如果一个服务操作需要调用另外一个服务，这是的事务就需要跨越多个服务了。在这种情况下，起始于某个服务的事务在调用另外一个服务的时候，需要以某种机制流转到另外一个服务，以使被调用的服务访问的资源自动加入进来。图3反映了这样一个跨越多个服务的分布式事务。

图3 跨越多个服务的事务

3、将对多个资源和服务的访问纳入同一个事务

如果将上面这两种场景（一个服务可以调用多个事务资源，也可以调用其他服务）结合在一起，对此进行延伸，整个事务的参与者将会组成如图4所示的树形拓扑结构。在一个基于分布式事务的服务调用中，事务的发起者和提交均系同一个，它可以是整个调用的客户端，也可以是客户端最先调用的那个服务。

图4 基于SOA分布式事务拓扑结构

较之基于单一资源访问的本地事务，分布式事务的实现机制要复杂得多。Windows平台提供了基于DTC分布式事务基础架构，下一篇文章中我将对针对该架构模型详细介绍分布式事务时如何工作的。

作者：Artech出处：http://artech.cnblogs.com本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

评论: 33　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

WCF技术剖析之三十：一个很有用的WCF调用编程技巧[下篇]

Artech — Fri, 08 Jan 2010 12:49:00 GMT

阅读: 1532 评论: 19 作者: Artech 发表于 2010-01-08 20:49 原文链接

在《上篇》中，我通过使用Delegate的方式解决了服务调用过程中的异常处理以及对服务代理的关闭。对于《WCF技术剖析（卷1）》的读者，应该会知道在第7章中我通过类似于AOP的方式解决了相似的问题，现在我们来讨论这个解决方案。

通过《服务代理不能得到及时关闭会有什么后果?》的介绍，我们知道了及时关闭服务代理的重要意义，并且给出了正确的编程方式。如果严格按照上面的编程方式，就意味着对于每一个服务调用，都要使用相同的代码进行异常处理和关闭或中断服务代理对象。按照我个人的观点，一个应用程序的每一个角落若充斥着相同的代码片断，这是一种很不好的设计。设计的目的在于实现代码的重用（Reuse），绝非代码的重复（Duplicate）。

所以现在我们的目的是将重复使用的代码进行单独维护，在使用到的地方进行重用。思路是这样：通过一个对象实现对客户端进行服务访问的方法调用的劫持，在该对象的内部实现真正的方法调用、服务代理关闭或中断，以及异常处理。这实际上是一种基于AOP的解决方案，在这里通过自定义真实代理（RealProxy）的方式来实现服务调用的AOP，这也是为何在本章的开始会花如此多的笔墨介绍真实代理和透明代理的一个重要原因。

下图所示的顺序图（Sequence Diagram）揭示了具体实现的原理：在定义的RealProxy（ServiceRealProxy）中实现了服务调用、异常处理和信道关闭或中断。客户端代码进行服务调用完全是通过自定义真实代理ServiceRealProxy的透明代理进行的，所以所有的方法调用都会直接分发给ServiceRealProxy对象。ServiceRealProxy根据当前方法调用的上下文（比如参数、MethodBase等）构建ChannelFactory对象并创建真正的服务代理对象。然后ServiceRealProxy借助创建出来的服务代理进行真正的服务调用，如果服务调用正常完成，则调用Close方法关闭服务代理，如果在调用过程中抛出CommunicationException和TimeoutException这两个异常，则调用Abort方法强行中断服务代理。最后，将服务调用的结果或抛出的异常通过TransparentProxy返回给客户端代码。

本例仅仅是为如何通过AOP进行WCF服务调用提供一种思路，并不是一个完备的解决方法（比如，没有考虑安全认证和客户端凭证的设置；没有考虑到双向通信和回调等），有兴趣的读者可以在此继承上进一步地完善。现在，就一步步地进行演示。

步骤一：创建ChannalFactory的静态工厂：ChannelFactoryCreator

由于服务调用通过服务代理完成，而ChannelFactory是服务代理的创建者，所以在这里先定义一个ChannelFactoryCreator的静态工厂类，通过它来创建或获取ChannelFactory方法。由于ChannelFactory的创建是一件费时的工作，为了提供更好的性能，和ClientBase一样采用了ChannelFactory的缓存机制（《ClientBase中对ChannelFactory的缓存机制》）。不过，这里的缓存机制比ClientBase的实现要简单得多，ClientBase通过终结点配置名称、终结点地址和回调对象三者进行缓存，这里仅仅是通过终结点配置名称进行ChannelFactory的缓存，因为我们假设客户端完全使用配置的终结点进行服务调用（这也是我们推荐的使用方式）。下面是整个ChannelFactory的静态工厂类的定义：

        1: using System;

       2: using System.Collections;

       3: using System.ServiceModel;

       4: namespace Artech.ServiceProxyFactory

       5: {

       6:     internal static class ChannelFactoryCreator

       7:     {

       8:         private static Hashtable channelFactories = new Hashtable();

       9:  

        public static ChannelFactory Create(string endpointName)

        {

            if (string.IsNullOrEmpty(endpointName))

            {

                throw new ArgumentNullException("endpointName");

            }

  

            ChannelFactory channelFactory = null;

  

            if(channelFactories.ContainsKey(endpointName))

            {

                channelFactory = channelFactories[endpointName] as ChannelFactory;

            }

  

            if (channelFactory == null)

            {

                channelFactory = new ChannelFactory(endpointName);

                lock (channelFactories.SyncRoot)

                {

                    channelFactories[endpointName] = channelFactory;

                }

            }

  

            return channelFactory;

        }

    }

}

ChannelFactoryCreator中通过一个Hashtable类型的静态变量保存所有创建出来ChannelFactory集合，Hashtable的Key为表示终结点配置名称的字符串。在Create方法中，先通过传入的终结点配置名称查看缓存中是否存在已经创建好的ChannelFactory对象，如果存在则直接返回，否则创建新的ChannelFactory对象,并在返回之前将其加入缓存。

步骤二：创建自定义RealProxy：ServiceRealProxy

ServiceRealProxy实现了真正的服务调用、异常处理和对服务代理的关闭或中断。ServiceRealProxy的构造函数参数endpointName表示用于服务调用而采用的终结点配置名称。在Invoke中，先借助于ChannelFactoryCreator获得的ChannelFactory创建服务代理对象。然后通过解析参数msg（表示对方法的调用）获得方法调用的参数，并在try控制块中通过反射，传入参数调用服务代理对象相应的方法，从而实现了对服务的调用。对于正常服务调用的结果，将其封装成ReturnMessage对象，并在返回之前调用Close方法关闭服务代理。

在catch控制块中，对抛出的异常进行处理，由于是通过反射方式实现的方法调用，得到的异常类型基本上都是TargetInvocationException，真正进行服务调用的异常被作为捕获异常的内部异常（InnerException）。所以，我们会判断内部异常是否为CommunicationException或TimeoutException，来决定是否通过调用Abort方法强行中断服务代理。捕获的异常被封装成ReturnMessage对象返回。

       1: using System;

       2: using System.Runtime.Remoting.Messaging;

       3: using System.Runtime.Remoting.Proxies;

       4: using System.ServiceModel;

       5: namespace Artech.ServiceProxyFactory

       6: {

       7:     public class ServiceRealProxy: RealProxy

       8:     {

       9:         private string _endpointName;

  

        public ServiceRealProxy(string endpointName):base(typeof(T))

        {

            if (string.IsNullOrEmpty(endpointName))

            {

                throw new ArgumentNullException("endpointName");

            }

            this._endpointName = endpointName;

        }

  

        public override IMessage Invoke(IMessage msg)

        {

            T channel = ChannelFactoryCreator.Create(this._endpointName).CreateChannel();

            IMethodCallMessage methodCall = (IMethodCallMessage)msg;

            IMethodReturnMessage methodReturn = null;

            object[] copiedArgs = Array.CreateInstance(typeof(object), methodCall.Args.Length) as object[];

            methodCall.Args.CopyTo(copiedArgs, 0);

            try

            {

                object returnValue = methodCall.MethodBase.Invoke(channel, copiedArgs);

                methodReturn = new ReturnMessage(returnValue, copiedArgs, copiedArgs.Length, methodCall.LogicalCallContext, methodCall);

                (channel as ICommunicationObject).Close();

            }            

            catch (Exception ex)

            {

                if (ex.InnerException is CommunicationException || ex.InnerException is TimeoutException)

                {

                    (channel as ICommunicationObject).Abort();

                }

  

                if (ex.InnerException != null)

                {

                    methodReturn = new ReturnMessage(ex.InnerException, methodCall);

                }

                else

                {

                    methodReturn = new ReturnMessage(ex, methodCall);

                }

            }

  

            return methodReturn;

        }

    }

}

步骤三：创建自定义服务代理工厂：ServiceProxyFactory

在本案例中，对于最终的客户端代码来说，它利用的是上面创建的自定义真实代理的透明代理间接地进行服务调用。而该透明代理就是客户端的服务代理，为了便于编程，在这里我们定义一个服务代理的静态工厂类：ServiceProxyFactory

       1: using System;

       2: namespace Artech.ServiceProxyFactory

       3: {

       4:     public static class ServiceProxyFactory

       5:     {

       6:         public static T Create(string endpointName)

       7:         {

       8:             if (string.IsNullOrEmpty(endpointName))

       9:             {

      10:                 throw new ArgumentNullException("endpointName");

      11:             }

      12:             return (T)(new ServiceRealProxy(endpointName).GetTransparentProxy());

      13:         }      

      14:     }

      15: }

步骤四：通过ServiceProxyFactory创建服务代理进行服务调用

由于重复繁琐的工作已经在ServiceRealProxy中完成，所以客户端进行服务调用的代码将会变得很简洁。为了验证在每次调用完毕后，是否如我们所愿将信道关闭，我们将ServiceProxyFactory应用到我们熟悉的计算服务的例子（终结点calculatorservice配置的绑定类型为WSHttpBinding）。

       1: ICalculator calculator = ServiceProxyFactory.Create("calculatorservice");

       2: for (int i = 1; i < 2000; i++)

       3: {

       4:     Console.WriteLine("{3}: x + y = {2} when x = {0} and y = {1}", 1, 2, calculator.Add(1, 2), i);

       5: }

输出结果：

    1 ： x + y = 3 when x = 1 and y = 2

    2 ： x + y = 3 when x = 1 and y = 2

    ......

    1999： x + y = 3 when x = 1 and y = 2

    2000： x + y = 3 when x = 1 and y = 2

从输出的结果可以看出，2000次服务调用成功完成，由此可以证明每次服务调用结束后，会话信道都被成功关闭。会话信道的自动关闭或中断还带来一个好处，由于每次使用的是新信道，所以即使上一个服务调用出错，也不会影响后续的调用。下面的例子证明了这一点：

       1: ICalculator calculator = ServiceProxyFactory.Create("calculatorservice");

       2: try

       3: { 

       4:     Console.WriteLine("x / y = {2} when x = {0} and y = {1}",2,0,calculator.Divide(2,0));

       5: }

       6: catch(Exception ex)

       7: {

       8:     Console.WriteLine(ex.Message);

       9: }

      10: Console.WriteLine("x + y = {2} when x = {0} and y = {1}",2,0,calculator.Add(2,0));

输出结果：

    The server was unable to process the request due to an internal error.  For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the  configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

    x + y = 2 when x = 2 and y = 0

评论: 19　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

WCF技术剖析之三十：一个很有用的WCF调用编程技巧[上篇]

Artech — Mon, 04 Jan 2010 11:46:00 GMT

阅读: 1570 评论: 38 作者: Artech 发表于 2010-01-04 19:46 原文链接

在进行基于会话信道的WCF服务调用中，由于受到并发信道数量的限制，我们需要及时的关闭信道；当遇到某些异常，我们需要强行中止（Abort）信道，相关的原理，可以参考我的文章《服务代理不能得到及时关闭会有什么后果?》。在真正的企业级开发中，正如我们一般不会让开发人员手工控制数据库连接的开启和关闭一样，我们一般也不会让开发人员手工去创建、开启、中止和关闭信道，这些工作是框架应该完成的操作。这篇文章，我们就来介绍如果通过一些编程技巧，让开发者能够无视“信道”的存在，像调用一个普通对象一样进行服务调用。

一、正常的服务调用方式

如果通过ChannelFactory创建用于服务调用的代理，下面的代码片段描述了客户端典型的服务调用形式：将服务调用在基于代理对象的using块中，并通过try/catch进一步对服务调用操作进行异常处理。当TimeoutException或者CommunicationException被捕获后，调用Abort方法将信道中止。当程序执行到using的末尾，Dispose方法会进一步调用Close方法对信道进行关闭。

     class Program

    {

        static void Main(string[] args)

        {

            using (ChannelFactory channelFactory = new ChannelFactory("calculatorservice"))

            {

                ICalculator calculator = channelFactory.CreateChannel();

                using (calculator as IDisposable)

                {

                    try

                    {

                        Console.WriteLine("x + y = {2} when x = {0} and y = {1}", 1, 2, calculator.Add(1, 2));

                    }

                    catch (TimeoutException)

                    {

                        (calculator as ICommunicationObject).Abort();

                        throw;

                    }

                    catch (CommunicationException)

                    {

                        (calculator as ICommunicationObject).Abort();

                        throw;

                    }

                }

            }

            Console.Read();

        }

    }

二、借助通过Delegate实现异常处理和服务代理的关闭

虽然上面的编程方式是正确的服务调用方式，但是在真正的应用中，如果在每处进行服务调用的地方都采用上面的方式，在我看来是不能容忍的。这不但会让你的程序显得臃肿不堪，而且带来非常多重复的代码,此外频繁创建ChannelFactory对性能也会有影响。我们可以通过一些公共个方法实现对重复代码（ChannelFactory的创建，服务调用的创建、中止和关闭，以及异常处理）。为此我创建了如下一个ServiceInvoker类型，通过两个重载的Invoke方法实现对目标服务的调用。

       1: using System;

       2: using System.Collections.Generic;

       3: using System.ServiceModel;

       4: namespace Artech.Lib

       5: {

       6:     public class ServiceInvoker

       7:     {

       8:         private static Dictionary<string, ChannelFactory> channelFactories = new Dictionary<string, ChannelFactory>();

       9:         private static object syncHelper = new object();

  

        private static ChannelFactory GetChannelFactory(string endpointConfigurationName)

        {

            ChannelFactory channelFactory = null;

            if (channelFactories.ContainsKey(endpointConfigurationName))

            {

                channelFactory = channelFactories[endpointConfigurationName] as ChannelFactory;

            }

  

            if (null == channelFactory)

            {

                channelFactory = new ChannelFactory(endpointConfigurationName);

                lock (syncHelper)

                {

                    channelFactories[endpointConfigurationName] = channelFactory;

                }

            }

            return channelFactory;

        }

  

        public static void Invoke(Action action, TChannel proxy)

        {

            ICommunicationObject channel = proxy as ICommunicationObject;

            if (null == channel)

            {

                throw new ArgumentException("The proxy is not a valid channel implementing the ICommunicationObject interface", "proxy");

            }

            try

            {

                action(proxy);

            }

            catch (TimeoutException)

            {

                channel.Abort();

                throw;

            }

            catch (CommunicationException)

            {

                channel.Abort();

                throw;

            }

            finally

            {

                channel.Close();

            }

        }

  

        public static TResult Invoke(Func function, TChannel proxy)

        {

            ICommunicationObject channel = proxy as ICommunicationObject;

            if (null == channel)

            {

                throw new ArgumentException("The proxy is not a valid channel implementing the ICommunicationObject interface", "proxy");

            }

            try

            {

              return  function(proxy);

            }

            catch (TimeoutException)

            {

                channel.Abort();

                throw;

            }

            catch (CommunicationException)

            {

                channel.Abort();

                throw;

            }

            finally

            {

                channel.Close();

            }

        }

  

        public static void Invoke(Action action, string endpointConfigurationName)

        {

            Guard.ArgumentNotNullOrEmpty(endpointConfigurationName, "endpointConfigurationName");

            Invoke(action, GetChannelFactory(endpointConfigurationName).CreateChannel());

        }

  

        public static TResult Invoke(Func function, string endpointConfigurationName)

        {

            Guard.ArgumentNotNullOrEmpty(endpointConfigurationName, "endpointConfigurationName");           

            return Invoke(function, GetChannelFactory(endpointConfigurationName).CreateChannel());

        }        

    }

}

处于对性能的考虑，避免对ChannelFactory的频繁创建，通过一个字典对象将创建出来的ChannelFactory缓存起来；两个Invoke方法中，服务的调用通过两个Delegate对象（Action和Func）表示，另一个参数表示终结点的配置名称。那么这时的服务调用就会变得相当简单：

       1: using System;

       2: using Artech.Lib;

       3: using Artech.WcfServices.Contracts;

       4: namespace Artech.WcfServices.Clients

       5: {

       6:     class Program

       7:     {

       8:         static void Main(string[] args)

       9:         {

      10:             int result = ServiceInvoker.Invokeint>(calculator => calculator.Add(1, 2), "calculatorservice");

      11:             Console.WriteLine("x + y = {2} when x = {0} and y = {1}", 1, 2, result);

      12:             Console.Read();

      13:         }

      14:     }

      15: }

三、对ServiceInvoker的改进

实际上，为了对服务调用实现细节进行进一步的封装，一般地我们可以将其定义在一个独立的层中，比如服务代理层（这里的层不一定像数据访问层、业务逻辑层一样需要一个明显的界限，这里可能就是一个单独的类型而已）。在这种情况下，我们可以上面的ServiceInvoker方法进行一定的改造，使之更加符合这种分层的场景。上面我们调用静态方法的形式进行服务的调用，现在我们需要的是：实例化服务代理对象，并调用相应的方法。为此，我创建了一个泛型的ServiceInvoker类型，该类型继承自上述的ServiceInvoker，泛型类型表示服务契约类型。ServiceInvoker定义如下：

       1: using System;

       2: namespace Artech.Lib

       3: {

       4:     public class ServiceInvoker:ServiceInvoker

       5:     {

       6:         public string EndpointConfigurationName

       7:         {get; private set;}

       8:  

       9:         public ServiceInvoker(string endpointConfigurationName)

      10:         {

      11:             Guard.ArgumentNotNullOrEmpty(endpointConfigurationName, "endpointConfigurationName");

      12:             this.EndpointConfigurationName = endpointConfigurationName;

      13:         }

      14:  

      15:         public void Invoke(Action action)

      16:         {

      17:             Invoke(action, this.EndpointConfigurationName);

      18:         }

      19:  

      20:         public TResult Invoke(Func function)

      21:         {

      22:             return Invoke(function, this.EndpointConfigurationName);

      23:         }

      24:     }

      25: }

通过传入终结点配置名称创建ServiceInvoker对象，直接通过调用基类的静态方法实现了两个Invoke方法。

在分层设计中，为每一个层定义的组件创建基类是一个很常见的设计方式。在这里，假设所有的服务代理类型均继承自基类：ServiceProxyBase，泛型类型为服务契约类型。同样通过传入终结点配置名称创建服务代理，并借助于通过Invoker属性表示的ServiceInvoker对象进行服务的调用。ServiceProxyBase定义如下：

       1: namespace Artech.Lib

       2: {

       3:     public class ServiceProxyBase

       4:     {

       5:         public virtual ServiceInvoker Invoker

       6:         { get; private set; }

       7:  

       8:         public ServiceProxyBase(string endpointConfigurationName)

       9:         {

      10:             Guard.ArgumentNotNullOrEmpty(endpointConfigurationName, "endpointConfigurationName");

      11:             this.Invoker = new ServiceInvoker(endpointConfigurationName);

      12:         }

      13:     }

      14: }

那么，具体的服务代理类型就可以通过如下的方式定义了：

       1: using Artech.Lib;

       2: using Artech.WcfServices.Contracts;

       3: namespace Artech.WcfServices.Clients

       4: {

       5:     public class CalculatorProxy : ServiceProxyBase, ICalculator

       6:     {

       7:         public CalculatorProxy():base(Constants.EndpointConfigurationNames.CalculatorService)

       8:         { }

       9:  

      10:         public int Add(int x, int y)

      11:         {

      12:             return this.Invoker.Invoke<int>(calculator => calculator.Add(x, y));

      13:         }

      14:     }

      15:  

      16:     public class Constants

      17:     {

      18:         public class EndpointConfigurationNames

      19:         {

      20:             public const string CalculatorService = "calculatorservice";

      21:         }

      22:     }

      23: }

那么现在服务代理的消费者（一般是Presenter层对象），就可以直接实例化服务代理对象，并调用相应的方法（这里的方法与服务契约方法一致）即可，所有关于服务调用的细节均被封装在服务代理中。

       1: using System;

       2: using Artech.Lib;

       3: using Artech.WcfServices.Contracts;

       4: namespace Artech.WcfServices.Clients

       5: {

       6:     class Program

       7:     {

       8:         static void Main(string[] args)

       9:         {

      10:             CalculatorProxy calculatorProxy = new CalculatorProxy();

      11:             int result = calculatorProxy.Add(1, 2);

      12:             Console.WriteLine("x + y = {2} when x = {0} and y = {1}", 1, 2, result);

      13:             Console.Read();

      14:         }

      15:     }

      16: }

四、局限

这个解决方案有一个很大的局限：服务方式不能包含ref和out参数，因为这两种类型的参数不能作为匿名方法的参数。

评论: 38　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

入围51CTO 2009年度“最受读者欢迎的IT图书作者”评选

Artech — Wed, 30 Dec 2009 10:10:00 GMT

阅读: 813 评论: 10 作者: Artech 发表于 2009-12-30 18:10 原文链接

《WCF技术剖析（卷1）》自出版以来，深受广大WCF爱好者的厚爱，并入围了51CTO 2009年度“最受读者欢迎的IT图书作者”评选，如果你觉得觉得这本书对你学习和使用WCF还有点帮助，你不妨投上一票（同时入围的还有园子里的一哥李会军同志）。

投票地址：http://book.51cto.com/exp/bookrating2009/author.php

姓名：蒋金楠

投票时间：2009年12月29日—2010年1月28日

投票方式：欢迎您，匿名

匿名投票：此方式将不能参与抽奖。
ID投票：注册为51CTO会员参与投票，将有机会获得每周的随机抽奖和颁奖现场的超级大奖。

投票规则：“作译者投票”限每位读者每天累积投票五票。

评论: 10　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

博客园-Artech

如何通过VPC在本机搭建局域网

步骤一：安装Microsoft Loopback Adapter网络适配器

步骤二、将VPC的网络适配器设置为Microsoft Loopback Adapter

谈谈分布式事务（Distributed Transaction）[共5篇]

[第1篇] SOA需要怎样的事务控制方式

[第2篇] 基于DTC的分布式事务管理模型之事务控制角色

[第3篇]基于DTC的分布式事务管理模型之事务登记于基于2PC的事务提交

[第4篇]System.Transactions事务之事务（Transaction）和可提交事务（CommittableTransaction）

[第5篇]System.Transactions事务之依赖事务（DependentTransaction）和事务范围（TransactionScope）

谈谈分布式事务之三: System.Transactions事务详解[下篇]

一、依赖事务（Dependent Transaction）

二、TransactionScope

谈谈分布式事务之三: System.Transactions事务详解[上篇]

一、System.Transactions.Transaction

二、 可提交事务(CommittableTransaction)

谈谈分布式事务之二：基于DTC的分布式事务管理模型[下篇]

一、事务登记（Transaction Enlisting）和事务提交树（Transaction Commit Tree）

二、基于两阶段提交（2PC：Two-Phase Commit）协议的事务提交机制

1、第一阶段（Phase I）：准备（Prepare）阶段

2、第二阶段（Phase II）：提交（Commit）或中止（Abort）

3、未决（In-Doubt）事务的处理

4、单阶段提交（SPC: Single-Phase Commit）优化

谈谈分布式事务之二：基于DTC的分布式事务管理模型[上篇]

一、应用（Application）、服务（Service）和组件（Component）

二、资源管理器（RM：Resource Manager）

三、事务管理器(Transaction Manager)

1、轻量级事务管理器（LTM: Lightweight Transaction Manager）

2、内核事务管理器（KTM：Kernel transaction Manager）

3、分布式事务协调器（DTC：Distributed Transaction Coordinator）

4、事务提升（Transaction Promotion）

谈谈分布式事务之一：SOA需要怎样的事务控制方式

一、 什么是事务（Transaction）

二、 事务的显式控制

三、分布式事务（Distributed Transaction）应用场景

WCF技术剖析之三十：一个很有用的WCF调用编程技巧[下篇]

步骤一：创建ChannalFactory的静态工厂：ChannelFactoryCreator

步骤二：创建自定义RealProxy：ServiceRealProxy

步骤三：创建自定义服务代理工厂：ServiceProxyFactory

步骤四：通过ServiceProxyFactory创建服务代理进行服务调用

WCF技术剖析之三十：一个很有用的WCF调用编程技巧[上篇]

一、正常的服务调用方式

二、借助通过Delegate实现异常处理和服务代理的关闭

三、对ServiceInvoker的改进

入围51CTO 2009年度“最受读者欢迎的IT图书作者”评选

二、可提交事务(CommittableTransaction)

一、什么是事务（Transaction）

二、事务的显式控制