适用于:Microsoft 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; 求和返回连接
如果用户请求了某个连接,将其释放,然后又从连接池对象中请求另一个连接,则根据连接池内的活动连接重新验证用户所使用的模拟机制将返回同一连接,而不需要重复访问 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 目录中更改此设置。