ASP.NET 2.0 中的SqlCacheDependency特性，and 明天開始上班啦！

ASP.NET中的Page Cache是個很有用的東東，只要簡單的在頁面上方加上一個OutputCache標籤，就可以讓頁面在制定的Duration內直接把自動儲存在緩衝中的頁面內容輸出，而不需要讓ASP.NET引擎再次執行頁面代碼，當然，節省這點執行時間並不是最主要的理由，主要理由是如果頁面內容是從資料庫中取出，那麼就可以省去串連資料庫、取資料的步驟，這個好處可大了。

 

PageCache有點小小的問題，比如，很多ASP.NET論壇的首頁就用了PageCache，所以在一個版裡面貼出的最新的文章並不會馬上反映到首頁上，而是需要等上一段時間。雖然有點無可奈何，但在某些場合（比如易趣用來顯示物品拍賣狀態的頁面），這種延遲是不允許的。

 

也即是說，ASP.NET裡面的Cache並不能自動根據資料庫中相應資料發生了變化，而使相應的Cache到期，ASP.NET 2.0中新增的SqlCacheDependency特性使這成為了可能。（當然，只要我們明白了ASP.NET 2.0中的大致實現方式，我們可以基於ASP.NET 1.0把這個特點實現出來，後面我總結了相應的方法。）

 

要在ASP.NET 2.0中應用SqlCacheDependency特性，步驟如下（基於大家手裡的Whidbey PDC版本）：

 

1、  使資料庫支援SqlCacheDependency

 

在.Net Framework 1.2的安裝目錄下（通常是WINDOWS\Microsoft.NET\Framework\v1.2.30703），有一個aspnet_regsqlcache.exe，這個命令列工具讓我們的SqlServer 7.0或者SqlServer 2000能支援SqlCacheDependency特性，

首先：“aspnet_regsqlcache –S 伺服器名稱 –U 登陸ID –P 密碼 –d 資料庫名稱 –ed”，這個命令使指定資料庫支援SqlCacheDependency，

 

然後我們再加入要追蹤的資料表：“aspnet_regsqlcache –S 伺服器名稱 –U 登陸ID –P 密碼 –d 資料庫名稱 –t 要追蹤的資料表的名稱 –et”，這個命令使指定的Table支援SqlCacheDependency。

 

它在幕後做了什麼事情呢？

 

首先，它在指定的資料庫中建立了一個Table，叫做“AspNet_SqlCacheTablesForChangeNotification”，這個表有三個欄位，“tableName”記錄要追蹤的資料表的名稱，“notificationCreated”記錄開始追蹤的時間，“changeId”是一個int類型的欄位，每當追蹤的資料表的資料發生變化時，這個欄位的值就加1。

 

它還會在指定的資料庫中增加幾個預存程序，用來讓ASP.NET引擎查詢追蹤的資料表的情況。

 

然後，它會給我們要追蹤的Table加上幾個Trigger，分別對應到Insert、Update、Delete操作，這幾個Trigger的語句非常簡單，就是把“AspNet_SqlCacheTablesForChangeNotification”表中對應“tableName”欄位為這個追蹤的表的名稱的記錄的“changeId”欄位加上一個1。

 

ASP.NET引擎通過執行它加上的預存程序“AspNet_SqlCachePollingStoredProcedure”，這個預存程序直接返回“AspNet_SqlCacheTablesForChangeNotification”表的內容，讓ASP.NET引擎知道哪個表的資料發生的變化。預設每500毫秒執行這個預存程序一次，不過可以在web.config裡面修改這個間隔時間，我的經驗是這個查詢操作也是很耗資源的，呵呵。

 

2、  web.config配置

 

在web.config裡面的配置再簡單不過了

 

<configuration>

       <!-- 加上合適的資料庫連接字串 -->

       <connectionStrings>

              <add name="SqlServerConnectionString"

              connectionString="server=sqlserver1;uid=sa;pwd=

password;database=PortalDB " />

       </connectionStrings>

       <system.web>

              <!-- 配置Cache一段，使之支援SqlCacheDependency -->

              <cache>

                     <sqlCacheDependency enabled="true" pollTime="500">

                            <databases>

                                   <add name=" PortalDB "

                                           connectionStringName=" SqlServerConnectionString " />

                            </databases>

                     </sqlCacheDependency>

              </cache>

       </system.web>

</configuration>

 

3、  在頁面上的outputCache標籤中指定SqlCacheDependency特性：

 

<%@ outputcache duration="9999" varybyparam="None" sqldependency="PortalDB:追蹤的資料表名稱" %>

 

只要在這個追蹤的Table上執行了Insert、Update、Delete操作，資料表上的Trigger就會將資料庫中“AspNet_SqlCacheTablesForChangeNotification”表的相應記錄的相應“changId”欄位值修改，然後ASP.NET引擎就會通過擷取新的值來得知追蹤的Table的內容發生了變化，自動使這個頁面的cache失效。

 

後話1、What about Yukon？

 

從上面可以知道，SqlServer並沒有內建自動追蹤資料表的資料變化，然後通知ASP.NET引擎的功能（這是肯定的，SqlServer都出來N久了），所以ASP.NET 2.0的開發組人為的加上了定製的Table、Trigger、StoredProcedure等等來實現資料更改追蹤。而Yukon已經不必這麼麻煩了，Yukon內建了一個Notification Delivery Service，這個服務會通過WebServer的80連接埠直接通知一個IIS內建的監聽器，然後這個監聽器再通知ASP.NET。

 

而且大家可以注意到，上面描述的那種追蹤方式只能追蹤到表一級的資料更改，即ASP.NET引擎最後只能得知某個表的資料發生了更改，而到底是哪一條記錄發生了更改，是追蹤不到的，而Yukon的Notification Delivery Service可以實現記錄一級的追蹤。

 

後話2、可以在現在的ASP.NET上實現嗎？

 

當然可以，我們先按照上面講的第一個步驟（或者自己定義一套規則來實現在資料庫中對Table資料變化的追蹤），依照葫蘆畫瓢來自己添加上這些Table、Trigger什麼的。

 

ASP.NET的PageCache有一個VaryByCustom屬性的，這個屬性可以實現讓我們自己定義“緩衝到期”的規則（確切的說，其實它是可以讓我們自訂快取頁面的版本，但間接可以實現自訂的緩衝“到期”啦，呵呵），只要我們在global.asa中重寫HttpApplication.GetVaryByCustomString()方法，這個方法根據輸入的參數字串，比如“CheckDBTable=Users”，查詢資料庫中那個“AspNet_SqlCacheTablesForChangeNotification”（或者你自己定義的某個追蹤記錄表），直接讓這個GetVaryByCustomString()方法返回“changeId”欄位的值即可。VaryByCustom的用法MSDN文檔上有詳細說明。

 

後話3、GolfClubShack示範程式

在部落格堂前面的某篇文章裡面，提供了一個基於ASP.NET 2.0的GolfClubShack網站的示範程式，是非常好的東東，在那個裡面可以看到包括SqlCacheDependency在內的眾多ASP.NET 2.0的特性的體現。現在網上完整的ASP.NET 2.0的示範程式不多，聽說MS內部已經把IBuySpy移植到ASP.NET 2.0上面了，不知詳情如何。而MS還在alpha階段的AspNetForums 2.0還是基於.Net Framework 1.1的（我以前一直是以為是基於最新的ASP.NET 2.0的，安裝了好半天，暈...）。

 

後話4、明天開始上班啦！！！

 

春節假期終於完了，這個春節沒有回家，留在深圳過年。今年深圳春節真冷啊，嗚嗚…家裡又沒有寬頻，只能撥接，痛苦不堪。從明天開始，又要開始工作了，不知道要幾天才能恢複春節顛倒過來的生物鐘。