適用於
Microsoft SQL Server?
Analysis Services
摘要
學習如何使用 Microsoft XML for Analysis Provider 附帶的連接池對象來開發適用於 Microsoft SQL Server
Analysis Services 的可伸縮客戶端和 Web 應用程序
簡介 資源管理是開發可伸縮客戶端和基於 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
\\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
或更高版本認為 XML for Analysis Provider 並不靈活
這意味著如果使用 IIS
或更高版本的默認設置
ADOConPool 和 OLEDBConPool 對象在緩存於 ASP 應用程序的應用程序或會話作用域中（換句話說
緩存於 ASP Application 或 Session 對象變量中）時將使用系統安全性上下文
請求和返回連接中介紹的模擬機制將無法正常工作
連接池對象在試圖驗證所有活動連接時將使用默認的 IIS 用戶
而不是當前連接的用戶
為了糾正這一錯誤
請將 IIS
或更高版本的配置數據庫中的 ASPTrackThreadingModel 設置更改為 True
更改此設置是為了防止 IIS 檢查 COM 組件的靈活性
但是
由於要進行封送處理和序列化
這會導致性能的降低
因此應該只在包含 Web 應用程序的虛擬目錄或 Web 目錄中更改此設置
平衡和收縮連接池 連接池中包含的連接數目沒有嚴格的限制
因為已將基礎管理機制設計為無阻礙機制
即客戶端應用程序在請求連接時應該都能獲得連接
正是由於無阻礙的特點
兩個對象才能使用相同的被動技術來管理連接
不過
也可以使用兩種不同的技術來管理連接池
平衡
和
收縮
平衡連接池 每當將連接返回到連接池（ADOConPool 對象使用 ReturnConnection 方法
而 OLEDBConPool 對象使用 ReturnSession 方法）時
都會用到平衡技術
連接池對象將把活動連接（已用連接和可用連接）的總數與 MaxSessions 屬性值進行比較
以確定是否有必要平衡連接池
如果活動連接的總數大於 MaxSessions 屬性值
則需要進行平衡
為了平衡連接池
連接池對象將根據自上次訪問每個可用連接以來經過的秒數對可用連接組進行排序
然後
該對象逐一刪除那些經
From:http://tw.wingwit.com/Article/program/SQLServer/201311/22161.html
