連接池與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;

　　求和返回連接

　　從連接池請求連接所用的機制不同于 OLE DB 資源池對基于 Web 的應用程序進行快速訪問所用的機制。連接池對象將活動連接池分成兩組：“可用連接”和“已用連接”?？捎眠B接由當前未分配給客戶端應用程序的連接組成；已用連接是指當前已分配給客戶端應用程序并被它使用的那些連接。

　　連接請求需要采用特殊的身份驗證和模擬機制。當通過應用程序請求連接時（ADOConPool 對象使用 GetConnection 方法，而 OLEDBConPool 對象使用 GetSession 方法），連接池試圖檢索可用連接，檢索條件是該連接使用的域名和用戶名與客戶端應用程序所用的安全標識符 (SID) 相同。如果找到匹配的可用連接，則將其返回到客戶端應用程序。

　　如果未找到與客戶端 SID 信息匹配的連接，連接池對象就會對客戶端請求中傳遞的連接信息進行分析，以確定連接池中是否已經存在同一個請求數據庫的可用連接。如果找到匹配的數據庫，連接池對象就會嘗試將客戶端請求的角色安全性與現有可用連接的角色安全性進行匹配。如果發現角色安全性是匹配的，連接池對象會接著比較可用連接的用戶名和客戶端請求的用戶名。如果用戶名也匹配，則將可用連接返回到客戶端應用程序。如果用戶名不匹配，則根據 Analysis 服務器上的角色安全性，使用客戶端請求的域和用戶名重新驗證可用連接，然后將其返回到發出請求的客戶端應用程序。

　　如果未找到匹配的角色安全性和數據庫，則在連接池中創建一個新的連接并將其分配給發出請求的客戶端應用程序。

　　與資源共享通常采用的方法相比，此方法還具備一個優點，即發出請求的客戶端應用程序可以重復使用具有同一角色安全性權限的現有活動連接，即使該連接最初是由其他用戶請求的。與可用連接相關聯的新用戶名仍然通過了驗證，因此能夠維護其安全性，并且可以將該連接提供給客戶端。這就縮短了為大量并發用戶提供服務的客戶端應用程序的連接時間并降低了費用。

　　對于那些執行大量操作并需要重復請求和返回連接的客戶端應用程序來說，該機制的效率更高?？梢詫⑼粋€活動且經過驗證的連接返回到發出請求的客戶端應用程序。

　　對于客戶端應用程序來說，將連接返回到連接池是一個非常簡單的過程?？蛻舳藨贸绦驅⑦B接引用傳遞回連接池對象（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 對象。

　　語法

　　對 ADOConPool 對象的有效引用。
　　in_bstrCn

　　適用于 ADO Connection 對象的連接字符串。
　　io_ppADOConnection

　　返回的 ADO Connection 對象引用。

　　備注
　　此方法試圖在創建新連接之前通過匹配連接和安全性信息，從連接池中請求現有的可用連接。有關請求連接的詳細信息，請參閱請求和返回連接。

　　ReturnConnection 方法
　　ReturnConnection 方法將 ADO Connection 對象返回到連接池。

　　語法

　　對 ADOConPool 對象的有效引用。
　　io_ppADOConnection

　　要返回到連接池的 ADO Connection 對象。

　　備注
　　使用此方法返回連接之后，連接池對象會自動平衡可用連接。有關平衡連接的詳細信息，請參閱平衡和收縮連接池。

　　Shrink 方法
　　當 Shrink 方法被調用時，它將終止過期的可用 ADO 連接對象并從連接池中將其刪除。

　　語法
　　C++

　　HRESULT Shrink()

　　Visual Basic

　　object.Shrink

　　object

　　對 ADOConPool 對象的有效引用。

　　備注
　　客戶端應用程序應該定期調用此方法，以終止并刪除已經超時的可用連接。有關收縮連接池的詳細信息，請參閱平衡和收縮連接池。

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 的客戶端應用程序，從而減少開發和實施過程中的開支，以低成本實現高性能。