适用于Microsoft® SQL Server&#; Analysis Services
摘要学习如何使用 Microsoft XML for Analysis Provider 附带的连接池对象来开发适用于 Microsoft SQL Server Analysis Services 的可伸缩客户端和 Web 应用程序
目录
简介
读者
连接池对象
使用连接池对象
请求和返回连接
平衡和收缩连接池
ADOConPool 对象
OLEDBConPool 对象
小结
其他信息
简介
资源管理是开发可伸缩客户端和基于 Web 的应用程序时需要考虑的一个重要问题在构造可为许多并发用户提供服务的客户端应用程序时资源管理的指导原则是尽可能迟地分配资源并尽可能早地解除资源分配资源（例如内存进程线程以及网络或数据库连接）的可用性与客户端应用程序的性能和用户的满意程度直接相关因此随着客户端应用程序的不断扩展资源管理也变得越来越重要了
通过对资源管理进行进一步的控制连接池可以降低可伸缩性的影响连接池使客户端应用程序能够在连接池与给定资源之间建立连接而不需要在每次使用时都重新建立连接在连接池中建立连接之后客户端应用程序可以重复使用该连接而不必执行完整的连接过程
因为客户端应用程序不需要重复地建立和关闭连接使用池缓沖的连接会显着提高连接性能此过程所需的时间对使用滞后时间较长的资源（例如 Internet 或网络连接）的客户端应用程序来说尤其重要当客户端应用程序不再需要连接时该连接就返回到连接池
除了可以提高性能以外使用连接池还可以更有效地管理资源同时又不会给客户端应用程序增加额外的资源管理费用连接池管理器可以根据需要分配和解除分配连接以维护连接池并且连接池中的连接可以供多个应用程序重复使用
为了支持使用 Microsoft SQL Server Analysis Services 的 Web 客户端应用程序的可伸缩性需要Microsoft XML for Analysis Provider 中已经实现了连接池功能XML for Analysis Provider 会自动使用连接池另外也可以对其他不需要使用由提供程序本身提供的 XML 连接的客户端应用程序使用此功能本文旨在介绍一些对象通过它们可以充分利用 Analysis Services 客户端应用程序中的连接池
读者
本文假定读者具备 SQL Server Analysis Services 以及 Microsoft ActiveX® 数据对象 (ADO) 和 OLE DB 数据访问技术的基础知识有关示例可在 Microsoft Visual Basic® 和 Microsoft Visual C++® 中找到
连接池对象
XML for Analysis Provider 中提供了两个对象ADOConPool 和 OLEDBConPoolADOConPool 对象用于管理 ADO 连接对象OLEDBConPool 对象用于管理 OLE DB 会话对象虽然两种对象提供的连接池类型不同但是它们均使用了相同的基础机制来管理连接池在本文中讨论这种共享的机制时用术语连接来描述 ADO 连接对象和 OLE DB 会话对象
连接池机制仅适用于 Microsoft SQL Server Service Pack (SP) 中包含的已经过更新的 Microsoft OLE DB Provider for OLAP Services (MSOLAP) OLE DB 提供程序
使用连接池对象
在支持 ADO 或 OLE DB 数据访问技术的编程语言中可以使用 ADOConPool 和 OLEDBConPool 对象但是要在 Visual C++ 程序中使用这些对象必须在程序中添加以下编译器指令以包含正确的头文件和属性
#include #include
#import \\msxaservdll 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 ARole 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 或更高版本认为 XML for Analysis Provider 并不灵活
这意味着如果使用 IIS 或更高版本的默认设置ADOConPool 和 OLEDBConPool 对象在缓存于 ASP 应用程序的应用程序或会话作用域中（换句话说缓存于 ASP Application 或 Session 对象变量中）时将使用系统安全性上下文请求和返回连接中介绍的模拟机制将无法正常工作连接池对象在试图验证所有活动连接时将使用默认的 IIS 用户而不是当前连接的用户
为了纠正这一错误请将 IIS 或更高版本的配置数据库中的 ASPTrackThreadingModel 设置更改为 True更改此设置是为了防止 IIS 检查 COM 组件的灵活性但是由于要进行封送处理和序列化这会导致性能的降低因此应该只在包含 Web 应用程序的虚拟目录或 Web 目录中更改此设置
平衡和收缩连接池
连接池中包含的连接数目没有严格的限制因为已将基础管理机制设计为无阻碍机制即客户端应用程序在请求连接时应该都能获得连接正是由于无阻碍的特点两个对象才能使用相同的被动技术来管理连接
不过也可以使用两种不同的技术来管理连接池平衡和收缩
平衡连接池
每当将连接返
