摘要：学习如何使用 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 目录中更改此设置。
不过，也可以使用两种不同的技术来管理连接池：“平衡”和“收缩”。
平衡连接池 每当将连接返回到连接池（ADOConPool 对象使用 ReturnConnection 方法，而 OLEDBConPool 对象使用 ReturnSession 方法）时，都会用到平衡技术。连接池对象将把活动连接（已用连接和可用连接）的总数与 MaxSessions 属性值进行比较，以确定是否有必要平衡连接池。如果活动连接的总数大于 MaxSessions 属性值，则需要进行平衡。
为了平衡连接池，连接池对象将根据自上次访问每个可用连接以来经过的秒数对可用连接组进行排序。然后，该对象逐一删除那些经过时间最长的可用连接，直到已用连接和可用连接的总数小于 MaxSessions 属性值或者没有任何活动的可用连接为止。
注意：平衡时不使用 Timeout 属性。 收缩连接池 每当客户端应用程序调用 ADOConPool 或 OLEDBConPool 对象的 Shrink 方法时，都会用到收缩技术。此技术是针对过期的可用连接而言的。连接池对象将把每个可用连接的上次访问时间与当前系统时间进行比较，如果相差的秒数大于 Timeout 属性值，就会删除该可用连接。
但是，这两种技术都不适用于管理已用连接。在完成一项操作之后，客户端应用程序负责将连接返回到连接池，这样就可以把已用连接作为可用连接进行重新分配。连接池对象并不试图管理已用连接，而是仅对可用连接进行平衡和收缩。使用此方法可以在性能和资源管理之间灵活地进行平衡。
ADOConPool 对象 ADOConPool 对象为使用 ADO 数据访问技术的客户端应用程序提供连接池，从而维护 ADO 连接对象的集合。
ADOConPool 对象具有以下属性和方法：
MaxSessions 属性 MaxSessions 属性用于限制连接池中 ADO 连接对象（包括可用连接和已用连接）的数目。
数据类型 长整型
权限 读/写
备注 由于连接池机制被设计为无阻碍机制，因而并不使用 MaxSessions 属性直接限制连接池的增长。而是由 ReturnConnection 和 Shrink 方法使用此值来平衡和收缩连接池。有关平衡和收缩的详细信息，请参阅本文前面介绍的平衡和收缩连接池。
Sessions 属性 Sessions 属性返回连接池中活动 ADO 连接对象的数目。
数据类型 长整型
权限 只读
备注 Sessions 属性报告由 ADOConPool 对象管理的连接（包括已用连接和可用连接）的总数。
Timeout 属性 Timeout 属性设置或返回可用 ADO Connection 对象保持活动状态的秒数。
数据类型 长整型
权限 读/写
备注 与 MaxSessions 属性类似，Timeout 属性由 Shrink 方法用来识别要从连接池中删除的活动可用连接。有关收缩的详细信息，请参阅平衡和收缩连接池。
GetConnection 方法 如果给定连接字符串，GetConnection 方法将返回 ADO Connection 对象。
语法
C
HRESULT GetConnection([in] BSTR in_bstrCn, [out,retval] IDispatch** io_ppADOConnection)
Visual BasicSet io_ppADOConnection = object.GetConnection(in_bstrCn As String)
object
对 ADOConPool 对象的有效引用。 in_bstrCn
适用于 ADO Connection 对象的连接字符串。 io_ppADOConnection
返回的 ADO Connection 对象引用。 备注 此方法试图在创建新连接之前通过匹配连接和安全性信息，从连接池中请求现有的可用连接。有关请求连接的详细信息，请参阅请求和返回连接。
ReturnConnection 方法 ReturnConnection 方法将 ADO Connection 对象返回到连接池。
语法
C
HRESULT ReturnConnection([in,out] IDispatch** io_ppADOConnection)
Visual Basicobject.ReturnConnection io_ppADOConnection
object
对 ADOConPool 对象的有效引用。 io_ppADOConnection
要返回到连接池的 ADO Connection 对象。 备注 使用此方法返回连接之后，连接池对象会自动平衡可用连接。有关平衡连接的详细信息，请参阅平衡和收缩连接池。
Shrink 方法 当 Shrink 方法被调用时，它将终止过期的可用 ADO 连接对象并从连接池中将其删除。
语法 C
HRESULT Shrink()
Visual Basic
object.Shrink
object
OLEDBConPool 对象OLEDBConPool 对象为使用 OLE DB 数据访问技术的客户端应用程序提供连接池，从而维护 OLE DB 会话对象的集合。OLEDBConPool 对象适用于那些直接使用 OLE DB 对客户端数据进行访问的应用程序，而大多数启用 Web 的应用程序应该使用 ADOConPool 连接池对象。
MaxSessions 属性 MaxSessions 属性用于限制连接池中 OLE DB 会话对象（包括可用会话和已用会话）的数目。
数据类型 长整型
权限 读/写
备注 由于连接池机制被设计为无阻碍机制，因而并不使用 MaxSessions 属性直接限制连接池的增长。而是由 ReturnSession 和 Shrink 方法使用此值来平衡和收缩连接池。有关平衡和收缩的详细信息，请参阅平衡和收缩连接池。
Sessions 属性 Sessions 属性返回连接池中活动 OLE DB 会话对象的数目。
数据类型 长整型
权限 只读
备注 Sessions 属性报告由 OLEDBConPool 对象管理的连接（包括已用连接和可用连接）的总数。
Timeout 属性 Timeout 属性设置或返回可用 OLE DB 会话对象保持活动状态的秒数。
数据类型 长整型
权限 读/写
备注 与 MaxSessions 属性类似，Timeout 属性由 Shrink 方法用来识别要从连接池中删除的活动可用连接。有关收缩的详细信息，请参阅平衡和收缩连接池。
GetSession 方法 如果给定一组 OLE DB 属性，GetSession 方法将返回 OLE DB 会话对象。
语法 C
HRESULT GetSession([in] int in_cPropSets, [in] DBPROPSET* in_pPropSets, [out,retval] IDBCreateCommand** io_ppSession )
in_cPropSets
in_pPropSets 参数中引用的 tagDBPROPSET 类型结构的长度（以字节为单位）。 in_pPropSets
用来标识和（如果必要）创建 OLE DB 会话对象的 tagDBPROPSET 类型结构的指针。 io_ppSession
返回的 OLE DB 会话对象引用。对象引用被转换为 IDBCreateCommand OLE DB 接口。 备注 此方法试图在创建新连接之前通过匹配连接和安全性信息，从连接池中请求现有的可用连接。有关请求连接的详细信息，请参阅请求和返回连接。
ReturnSession 方法 ReturnSession 方法将 OLE DB 会话对象返回到连接池。
语法 C
HRESULT ReturnSession([in,out] IDBCreateCommand** io_ppSession);
io_ppSession
返回到连接池的 OLE DB 会话对象。 备注 使用此方法返回连接之后，连接池对象会自动平衡可用连接。有关平衡连接的详细信息，请参阅平衡和收缩连接池。
Shrink 方法 当 Shrink 方法被调用时，它将终止过期的可用 OLE DB 会话对象并从连接池中将其删除。
语法 C
HRESULT Shrink()
备注 客户端应用程序应该定期调用此方法，以终止并删除已经超时的可用连接。有关收缩连接池的详细信息，请参阅平衡和收缩连接池。
小结 连接池是一种有效的资源管理方法。使用作为 Microsoft XML for Analysis Provider 的一部分提供的连接池对象，可以将这种资源管理方法扩展到使用 Microsoft SQL Server 2000 Analysis Services 的客户端应用程序，从而减少开发和实施过程中的开支，以低成本实现高性能。