经典技术文章翻译(1):COM+集成:.NET Enterprise Services 如何帮你建立分布式应用(2)

管理珍贵的资源

      我现在开始另外一个管理对象引用的话题 ' ，另外一个问题你必须注意 CLR 靠垃圾收集器回收内存。  这是个重要的事情因为它要自动帮助避免内存泄露并且释放闲置的内存。非常不幸的是，  垃圾收集器使得内存管理变的容易，但是他同样带来了其他问题，比如管理 COM+ 设计的对象变的困难。因此高效地管理资源是建立可伸缩的系统的关键，这正是 COM+  的设计目标，你需要知道如果合理地释放基于 CLR 的资源。
      考虑  CLR 类使用到了 SqlConnection  对象连接数据库，  如下所示 :

public void UseADatabase(void)

{

 System.Data.SqlClient.SqlConnection =

      new System.Data.SqlClient.SqlConnection(…);

    …// use connection to execute statements

}

在 UseADatabase 方法的结束部分，  SqlConnection  对象被释放。  SqlConnection 对象封装了处理数据库的连接并且为了效率考虑被 ADO.NET 底层机制池化 (Beta 1  使用 COM+  对象池 ; Beta 2 ，  使用了类似 COM+  对象池的机制 ) 。  问题是  SqlConnection 对象管理的连接何时归还到对象池 ?  不等垃圾收集器进入，就意识到 SqlConnection  对象不在被使用，就调用终结器。 finalizer  把连接归还给对象池，  然后 SqlConnection 对象的内存就被回收。
       问题是数据库连接资源是非常珍贵的资源，你不能让他们无约束地飘荡在内存里，直到垃圾收集器来回收。  需要一些方法来回收这样的资源。一种方式就是强制垃圾收集器执行回收工作，如下所示 :

public void UseADatabase(void)

{

 System.Data.SqlClient.SqlConnection conn =

      new System.Data.SqlClient 。SqlConnection(…);

 … // use connection to execute statements

 conn = null;

 System.GC.Collect();   

}

然而，这个方法相当的笨拙且有很多潜在问题。

      更好的方法是调用 SqlConnection  对象实现的接口的  IDisposable.Dispose 方法。  IDisposable  接口在 System 命名空间，它规范拥有昂贵的要清理的资源的对象通过客户端定义操作释放资源代理垃圾收集器回收的行为。 SqlConnection 实现了 Dispose ，快速归还对象给对象池  ( 事实上和调用 finalizer 的作用一样 ) 。
       下面代码是新版本的 UseADatabase 方法，它显示的清除了 SqlConnection 。

public void UseADatabase(void)

{

 System.Data.SqlClient.SqlConnection conn =

      new System.Data.SqlClient.SqlConnection(…);

 try

 {

    … // use connection to execute statements

 }

 finally

 {

    Conn.Dispose();

 }

}

注意到 Dispose 出现在 finally 块里确保它可以执行，不管是否抛出异常。
       那这个和 COM+ 与服务类有什么关系呢 ?  首先，你的服务类很可能使用数据库连接和其它昂贵的资源，  所以如果你希望系统净化，你就应该知道如果合理地释放资源。  第二是，  所有基于 CLR  服务类  实现了 IDisposable.Dispose 方法，  因为基类， ServicedComponent 。你应该知道当客户端调用 Dispose 时发生了什么。默认实现的行为取决于你的组件服务类  使用了什么运行时服务。如果你没使用对象池激活，  Dispose 就会立即调用  finalizer ( 如果已经被垃圾收集器回收，就不会再调用 ) 。如果你的组件服务类  使用了对象池而不是 JIT  激活，  Dispose 调用 Deactivate 去通知对象已经离开它当前的上下文。然后它就调用  CanBePooled  去询问对象是否重用或销毁。  如果 CanBePooled 返回 true ，  对象会返回到对象池里。  返回 false ，  对象的 finalizer 就会调用  ( 如果已经被垃圾收集器回收，就不会再调用 ) 。  非常重要是客户端为池化的对象调用方法 Dispose ，如下所示。

public void UseAPooledObject(void)

{

 MyPooledCfgClass pcc = new MyPooledCfgClass();

 try

 {

    …// use pooled object to do something

 }

 finally

 {

    Pcc.Dispose();

 }

}

       如果不调用 Dispose ，对象  ( 如描述的数据库连接 ) ，  只有等到垃圾收集器回收资源。  最后，  如果你自己实现组件服务类的 Dispose 方法，  你必须调用基类的实现去实现这些描述的行为。

[ Synchronization(SynchronizedOption.Required) ]

public class MyCfgClass : ServicedComponent

{

 public new void Dispose()

 {

    … // do whatever

    Base.Dispose(); // call base to clean up

 }

}

     你或许想知道  JIT  激活和反激活一个对象在方法的结束。  那解决了资源的管理问题了吗 ? 答案是否。  反激活使得对象在结束调用前释放自己成员所有的资源，  同样包括想使用相同资源的的每个方法调用。你可以通过不保存任何资源的方式达到这个目的。如果你没有选择  JIT  激活  和反激活在每次方法调用的结尾，  知道客户端调用 Dispose 实际上是强制你的对象重激活到饭激活并且重新终结一次。通常情况下，  到 CLR 的转换不会改变的 JIT  激活规则。  应该避免使用它除非运行时服务需要它  ( 比如声明的服务 )  因为它不会更高效，  且  比你自己管理昂贵的资源效率低。

展望

      ServicedComponent  类继承自  System 。 ContextBoundObject ，  它又继承自 System 。 MarshalByRefObject ，  这个基类可以使对象可以通过 .NET remoting 机制  被访问到。在 Remoting 顶层  上进行 CLR/COM+ 集成有两个好处。首先你能通过 Remoting 层使用 SOAP 访问 COM+  运行时服务的远程对象。但是你不能够使用 SOAP 传递事务到另外的进程  ( 非你所愿，  但道理如此 ) 。  第二点，打开了新版的新的基于 CLR Remoting 上下文架构实现的 COM+  运行时服务的方式  这是现在的 COM+ 所没有用到的。  将来一定会够发生。  真要这样，服务就可以与 SOAP 或者其他的传输无逢集成，并且上下文就可以真的可以扩展了。那时，  已经正确跨出一大步的 CLR  就会使得 COM+ 编程变的更加容易。