‘' 植入带数据的记录集
rs.Open strQuery, strProv
‘' 现在断开记录集同数据提供者和数据源的连接
rs.ActiveConnection = Nothing ‘' 第 2 步
有关连接池的详细信息，请参阅 ADO 和 SQL Server（英文）引用。
技巧 6：妙用 Session 对象
在肯定了在 Applications 和 Sessions 中缓存的优点之后，我们建议您避免使用 Session 对象。下面将会谈到，当用于忙碌站点时，Sessions 有几个缺点。所谓忙碌，通常是指站点每秒请求数百页或同时有数千个用户。该技巧对于必须进行水平扩展的站点，即那些利用多个服务器来适应负载或执行容错功能的站点来说，更加重要。对于较小的站点，如 intranet 站点，Sessions 的便利，与开销相比也是值得的。
为了翻新，ASP 自动为每个访问 Web 服务器的用户创建一个 Session。每个 Session 有大约 10 KB 内存开销（在存储在 Session 中的任何数据中是最高的），并使所有的请求都慢了一点。Session 一直保持活动状态，直到达到可配置的超时（通常 20 分钟）为止。
Session 最大的问题不是性能而是可伸缩性。Session 不能跨越 Web 服务器；一旦在一个服务器上创建了 Session，它的数据就保持在那里。这意味着，如果您在 Web 领域中使用 Sessions，您将不得不为每个用户的请求设计一种策略，以便始终将这些请求引向用户的 Session 所在的服务器。这被称为将用户"粘"到 Web 服务器上。术语"粘性会话"即来源于此。由于 Session 没有保持到磁盘上，所以，当 Web 服务器崩溃时，被"粘住"的用户将丢失他们的 Sessions 状态。
用于实施粘性会话的策略包括硬件和软件解决方案。如 Windows 2000 Advanced Server 中的网络负载平衡解决方案和 Cisco 公司的"本地指向器"解决方案可以实施粘性会话，但以牺牲一些可伸缩性为代价。这些解决方案并不完美。我们不主张您现在全盘推翻您的软件解决方案（我们过去常用 ISAPI 筛选器和 URL 矫直对方案进行检查）。
Application 对象也不能跨越服务器；如果您需要在 Web 领域内共享并更新 Application 数据，则需要使用后端数据库。但只读的 Application 数据在 Web 领域中仍然有用。
如果只是为了增加正常运行时间（用于处理故障转移和服务器维护），大多数执行重要任务的站点将需要部署至少两台 Web 服务器。所以，在设计执行重要任务的应用程序时，您将需要实施"粘性会话"，或者简单地避开 Sessions 以及其他任何在单个 Web 服务器上存储用户状态的状态管理技术。
如果当前没有使用 Sessions，请确保将它们关闭。可以通过"Internet 服务管理器"（请参阅 ISM 文档）来为应用程序执行该操作。如果决定使用 Sessions，可以采取几个方法来将对性能的影响降低到最小。