適用於
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 和 OLEDBConPool
ADOConPool 對象用於管理 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 目錄中更改此設置
平衡和收縮連接池
連接池中包含的連接數目沒有嚴格的限制因為已將基礎管理機制設計為無阻礙機制即客戶端應用程序在請求連接時應該都能獲得連接正是由於無阻礙的特點兩個對象才能使用相同的被動技術來管理連接
不過也可以使用兩種不同的技術來管理連接池平衡和收縮
平衡連接池
每當將連接返
From:http://tw.wingwit.com/Article/program/SQLServer/201311/21993.html
