连接池与SQL Server 2000 Analysis Services

　　摘要：学习如何使用 Microsoft XML for Analysis Provider 附带的连接池对象来开发适用于 Microsoft SQL Server 2000 Analysis Services 的可伸缩客户端和 Web 应用程序。

　　简介

　　资源管理是开发可伸缩客户端和基于 Web 的应用程序时需要考虑的一个重要问题。在构造可为许多并发用户提供服务的客户端应用程序时，资源管理的指导原则是尽可能迟地分配资源，并尽可能早地解除资源分配。资源（例如内存、进程线程以及网络或数据库连接）的可用性与客户端应用程序的性能和用户的满意程度直接相关。因此，随着客户端应用程序的不断扩展，资源管理也变得越来越重要了。

　　通过对资源管理进行进一步的控制，连接池可以降低可伸缩性的影响。连接池使客户端应用程序能够在连接池与给定资源之间建立连接，而不需要在每次使用时都重新建立连接。在连接池中建立连接之后，客户端应用程序可以重复使用该连接，而不必执行完整的连接过程。

　　因为客户端应用程序不需要重复地建立和关闭连接，使用池缓冲的连接会显著提高连接性能。此过程所需的时间对使用滞后时间较长的资源（例如 Internet 或网络连接）的客户端应用程序来说尤其重要。当客户端应用程序不再需要连接时，该连接就返回到连接池。

　　除了可以提高性能以外，使用连接池还可以更有效地管理资源，同时又不会给客户端应用程序增加额外的资源管理费用。连接池管理器可以根据需要分配和解除分配连接以维护连接池，并且连接池中的连接可以供多个应用程序重复使用。

　　为了支持使用 Microsoft SQL Server 2000 Analysis Services 的 Web 客户端应用程序的可伸缩性需要，Microsoft XML for Analysis Provider 中已经实现了连接池功能。XML for Analysis Provider 会自动使用连接池，另外也可以对其他不需要使用由提供程序本身提供的 XML 连接的客户端应用程序使用此功能。本文旨在介绍一些对象，通过它们可以充分利用 Analysis Services 客户端应用程序中的连接池。

　　读者

　　本文假定读者具备 SQL Server 2000 Analysis Services 以及 Microsoft ActiveX? 数据对象 (ADO) 和 OLE DB 数据访问技术的基础知识。有关示例可在 Microsoft Visual Basic? 和 Microsoft Visual C++? 中找到。

　　连接池对象

　　XML for Analysis Provider 中提供了两个对象：ADOConPool 和 OLEDBConPool。ADOConPool 对象用于管理 ADO 连接对象；OLEDBConPool 对象用于管理 OLE DB 会话对象。虽然两种对象提供的连接池类型不同，但是它们均使用了相同的基础机制来管理连接池。在本文中讨论这种共享的机制时，用术语“连接”来描述 ADO 连接对象和 OLE DB 会话对象。

　　连接池机制仅适用于 Microsoft SQL Server 2000 Service Pack 1 (SP1) 中包含的、已经过更新的 Microsoft OLE DB Provider for OLAP Services 8.0 (MSOLAP.2) OLE DB 提供程序。

　　使用连接池对象

　　在支持 ADO 或 OLE DB 数据访问技术的编程语言中，可以使用 ADOConPool 和 OLEDBConPool 对象。但是，要在 Visual C++ 程序中使用这些对象，必须在程序中添加以下编译器指令以包含正确的头文件和属性：

#include
#include
#import "\\msxaserv.dll" rename("tag_inner_PROPVARIANT",
"tagPROPVARIANT") rename("_LARGE_INTEGER","")
rename("_ULARGE_INTEGER","")
using namespace MSXmlAnalysisSCLib;

　　求和返回连接

　　从连接池请求连接所用的机制不同于 OLE DB 资源池对基于 Web 的应用程序进行快速访问所用的机制。连接池对象将活动连接池分成两组：“可用连接”和“已用连接”。可用连接由当前未分配给客户端应用程序的连接组成；已用连接是指当前已分配给客户端应用程序并被它使用的那些连接。

　　连接请求需要采用特殊的身份验证和模拟机制。当通过应用程序请求连接时（ADOConPool 对象使用 GetConnection 方法，而 OLEDBConPool 对象使用 GetSession 方法），连接池试图检索可用连接，检索条件是该连接使用的域名和用户名与客户端应用程序所用的安全标识符 (SID) 相同。如果找到匹配的可用连接，则将其返回到客户端应用程序。

　　如果未找到与客户端 SID 信息匹配的连接，连接池对象就会对客户端请求中传递的连接信息进行分析，以确定连接池中是否已经存在同一个请求数据库的可用连接。如果找到匹配的数据库，连接池对象就会尝试将客户端请求的角色安全性与现有可用连接的角色安全性进行匹配。如果发现角色安全性是匹配的，连接池对象会接着比较可用连接的用户名和客户端请求的用户名。如果用户名也匹配，则将可用连接返回到客户端应用程序。如果用户名不匹配，则根据 Analysis 服务器上的角色安全性，使用客户端请求的域和用户名重新验证可用连接，然后将其返回到发出请求的客户端应用程序。

　　如果未找到匹配的角色安全性和数据库，则在连接池中创建一个新的连接并将其分配给发出请求的客户端应用程序。

　　与资源共享通常采用的方法相比，此方法还具备一个优点，即发出请求的客户端应用程序可以重复使用具有同一角色安全性权限的现有活动连接，即使该连接最初是由其他用户请求的。与可用连接相关联的新用户名仍然通过了验证，因此能够维护其安全性，并且可以将该连接提供给客户端。这就缩短了为大量并发用户提供服务的客户端应用程序的连接时间并降低了费用。

　　对于那些执行大量操作并需要重复请求和返回连接的客户端应用程序来说，该机制的效率更高。可以将同一个活动且经过验证的连接返回到发出请求的客户端应用程序。

　　对于客户端应用程序来说，将连接返回到连接池是一个非常简单的过程。客户端应用程序将连接引用传递回连接池对象（ADOConPool 对象使用 ReturnConnection 方法，而 OLEDBConPool 对象使用 ReturnSession 方法）。连接池对象验证传递回的连接对象是否确实属于该连接池，然后才将其放回可用连接池中。

　　注意事项

　　如果用户请求了某个连接，将其释放，然后又从连接池对象中请求另一个连接，则根据连接池内的活动连接重新验证用户所使用的模拟机制将返回同一连接，而不需要重复访问 Analysis 服务器。如果用户释放第一个连接请求后其角色权限发生了变化，则第二个请求将返回具有最初角色权限的相同连接。

　　例如，某个用户在 Analysis 服务器上的角色为 Role A。Role A 使用户可以对两个多维数据集 Cube A 和 Cube B 运行查询。当此用户所使用的客户端应用程序首次请求连接时，返回的连接有权访问 Cube A 和 Cube B。客户端应用程序运行查询，然后释放连接。Analysis 服务器的管理员现在将 Role A 的访问权限更改为只能访问 Cube A。如果此用户的客户端应用程序请求另一个连接，首次请求时创建的连接将再次返回到该客户端应用程序，但是，它仍然有权访问 Cube A 和 Cube B。虽然 Role A 对应的用户当前只能访问 Cube A，但仍会对 Cube B 继续执行查询，就好象此用户对该多维数据集仍具有访问权限一样。

　　只有重新分配活动连接，才会出现这种问题；新创建的连接始终会跟 Analysis 服务器进行验证。如果上面的示例中客户端应用程序首次请求的活动连接已超时，系统就会为该客户端应用程序分配一个新创建的连接，这时该连接就具有正确的角色权限。

　　对于 Web 应用程序，解决此问题的最简单的方法是每当 Analysis 服务器上的角色发生改变时都重新启动 Microsoft Internet Information Services (IIS)，强制应用程序在请求连接时重新加载并使用新的角色权限。

　　鉴于 IIS 线程管理的特性，当您创建基于 Web 的应用程序时，在 Active Server Pages (ASP) Web 应用程序中使用 ADOConPool 和 OLEDBConPool 连接池对象时应该特别小心。IIS 检查每个 COM 组件以确定其灵活性（COM 组件的线程处理和封送处理能力）。XML for Analysis Provider 支持自由线程模块，但并不提供自由线程封送拆收器 (FTM)。正是由于这个原因，IIS 5.0 或更高版本认为 XML for Analysis Provider 并不灵活。

　　这意味着如果使用 IIS 5.0 或更高版本的默认设置，ADOConPool 和 OLEDBConPool 对象在缓存于 ASP 应用程序的应用程序或会话作用域中（换句话说，缓存于 ASP Application 或 Session 对象变量中）时将使用系统安全性上下文。请求和返回连接中介绍的模拟机制将无法正常工作。连接池对象在试图验证所有活动连接时将使用默认的 IIS 用户，而不是当前连接的用户。

　　为了纠正这一错误，请将 IIS 5.0 或更高版本的配置数据库中的 ASPTrackThreadingModel 设置更改为 True。更改此设置是为了防止 IIS 检查 COM 组件的灵活性，但是，由于要进行封送处理和序列化，这会导致性能的降低，因此应该只在包含 Web 应用程序的虚拟目录或 Web 目录中更改此设置。