WCF：使用事务管理状态和错误恢复

WCF：使用事务管理状态和错误恢复2011-08-04 MSDN Juval Lowy目录

状态管理和事务

单调用事务性服务

实例管理和事务

基于会话的服务和 VRM

事务性持久服务

事务性行为

向 IPC 绑定添加上下文

InProcFactory 和事务

编程中的一个根本问题就是错误恢复。发生错误后，应用程序必须自行恢复到产生错误之前的状态。请考虑这样一个应用程序，它试图执行一项由若干个更小操作组成的操作，这些小操作可能并行发生，而且每个单独操作的成功或失败都与其他操作无关。任何一个更小操作出现错误，都意味着系统处于不一致的状态。

以银行业务应用程序为例，该应用程序通过将资金划入一个帐户并从另一帐户转出资金，来在两个帐户之间转移资金。从一个帐户转出资金成功但将其划入另一帐户失败就属于不一致的状态，因为资金无法同时存在于两个位置中；同样，转出资金失败但划入资金成功也会导致不一致状态，此时资金失踪。通常总是由应用程序通过将系统恢复为原始状态来从错误中恢复。

由于某些原因，做比说要难得多。首先，对于一项大的操作，如果大量排列部分成功、部分失败，则操作很快就会变得无法控制。这将导致代码容易毁坏，使开发和维护费用变得非常昂贵，且代码经常在实际中不起作用，其原因是开发人员通常只处理易于恢复的情形，在此类情况下，他们能够意识到问题所在且知道如何处理。其次，您的复合操作可能是更大操作的一部分，即使您的代码执行完美无缺，如果不属您控制范围的事物出错，您也必须撤消该操作。这意味着操作的管理和协作参与方之间需要紧密配合。最后，还需将您的工作与其他需要和系统交互的人员隔离开来，因为如果您以后通过回滚某些操作来从错误中恢复，会隐式将其他人员置于错误状态中。

如您所见，手动编写可靠的错误恢复代码实际上是不可能的，这一点人们早已认识到了。自二十世纪六十年代在业务环境中使用软件起，人们就非常清楚必须要有一个更好的方法来管理恢复。这个方法就是：事务。事务是一组操作，其任何一个操作的失败都会导致整组失败，就象一个原子操作一样。使用事务时，无需编写恢复逻辑，因为没有要恢复的内容。当所有操作均成功时，没有要恢复的内容；当所有操作均失败时，不会对系统状态产生任何影响，因此也没有要恢复的内容。

使用事务时，关键是要使用事务性资源管理器。该资源管理器能够在事务中止时回滚事务期间所发生的全部更改，并在提交事务时保持更改。资源管理器还提供隔离功能；也就是说，当事务正在进行中时，资源管理器会阻止所有方（包括事务在内）访问事务和看到更改（这些更改仍能够回滚）。这也意味着，事务永远不应访问非资源管理器，因为在事务中止时对此类管理器所做的任何更改都不会回滚，这就需要进行恢复。

传统意义上，资源管理器为持久资源，如数据库和消息队列。然而，在 2005 年 5 月刊的《MSDN 杂志》中，我在一篇名为“无法提交？.NET 中的不稳定资源管理器将事务引入公共类型”的文章中介绍了实现常用不稳定资源管理器（VRM）（名为 Transactional<T>）的技术：

public class Transactional<T> : ...
{
  public Transactional（T value）;
  public Transactional（）;
  public T Value
  {get;set;}
  /* Conversion operators to and from T */
}