ASP.NET Crashkurs - Caching

Veröffentlicht: 14. Sep 2005

Auszug aus dem Buch "ASP.NET 2.0 Crashkurs - Schnelleinstieg in neue Technologien und Tools" von Hannes Preishuber".

Dieses Buch ist Ihr Schnelleinstieg in die Neuerungen von ASP.NET 2.0. Dabei werden nicht einfach nur neue Features und Möglichkeiten aufgezählt, sondern deren Anwendung in einem sinnvollen praxisnahen Rahmen erläutert. Auch die wichtigsten Grundkonzepte der Programmierung mit ASP.NET werden - soweit wie nötig - thematisiert.

Das Buch ist deswegen sowohl für Programmierer geeignet, die sich über die neuen Möglichkeiten von ASP.NET 2.0 informieren wollen, als auch für erfahrene Entwickler, die einen komprimierten Einstieg in die Webprogrammierung mit ASP.NET 2.0 suchen.

Diesen Artikel können Sie dank freundlicher Unterstützung von Microsoft Press auf MSDN Online lesen. Microsoft Press ist ein Partner von MSDN Online.

Auf dieser Seite

 Grundlagen
 Output Caching
 Daten-Caching

Grundlagen

Leistungsfähige Anwendungen zu entwickeln, wird vielfach als geheime Wissenschaft gehandelt. In der Tat können speziell bei Webanwendungen erhebliche Spitzenbelastungen auftreten. Nach dem Versand eines Newsletters beispielsweise klicken schon mal einige tausend Benutzer binnen weniger Minuten auf einen in der E-Mail eingeschlossenen Hyperlink. Vielfach wird versucht, diesem Aufkommen mit einer mehrschichtigen Anwendungsarchitektur zu begegnen. Die Kommunikation der dazu verwendeten Softwareschichten und damit der entsprechenden Objekte wird über Remoting oder Enterprise Services implementiert. Das mag für den Entwickler eine Herausforderung sein oder sich in den Projektspezifikationen gut lesen - notwendig ist es selten.

Viel sinnvoller und vor allem einfacher ist es, mit der ASP.NET-Caching-Funktionalität datenintensive Prozesse zu reduzieren. Es geht im Wesentlichen darum, Daten im Arbeitsspeicher besser zwischenzuspeichern als dauernd von der Datenbank zu holen. Auf diese Weise arbeiten Browser und Proxy Server schon seit vielen Jahren.

Die Artikeldaten eines Online-Shops ändern sich in der Praxis selten und müssen daher auch nicht bei jeder Suchanfrage neu aus der Datenbank geladen werden. Die Daten werden stattdessen im Arbeitsspeicher zwischengespeichert. Das verringert die Belastung des SQL Servers. Außerdem ist ein Lesezugriff auf den Arbeitsspeicher um ein Vielfaches schneller als auf eine Festplatte. Was damit möglich ist, zeigt die Web Seite www.asp.net. Diese wird nur wegen der Ausfallsicherheit mit zwei Windows 2003-Webservern betrieben. Als dritter Server kommt ein SQL Server zum Einsatz. In dieser Hardware Architektur ist keine externe Objektkommunikation notwendig. Dennoch genügt diese Hardwarekonfiguration für das Aufkommen - so hat z. B. der Forumbereich mehr als eine halbe Million registrierte Benutzer.

Caching ist eine einfache, anspruchslose Technologie. Sogar zu einem späteren Zeitpunkt lässt sich an kritischen Stellen der Anwendung Caching implementieren und das, ohne große Codeänderungen vornehmen zu müssen. Dabei verwaltet sich das Caching weitgehend selbst. Wenn der Arbeitsspeicher zur Neige geht, werden veraltete oder selten genutzte Daten im Cache einfach entladen. Sogar ein selbst pflegender Cache ist möglich. Wenn sich die Quelldaten ändern, kann der Cache automatisch erneuert werden. Gerade hier wird es die Kenner freuen, zu hören, dass jetzt auch eine SQL-Server-Cache-Abhängigkeit definiert werden kann. Für jede Anforderung bietet Caching das Richtige.

In ASP.NET wird die Caching-Technologie in zwei Gruppen unterteilt: Output Caching und Daten-Caching.

 

Output Caching

Das Erstellen des HTML-Codes aus der ASPX-Seite braucht ziemlich viel Zeit. Dieser Vorgang wird Rendern genannt. Da die gleiche ASPX-Seite mit gleichen Daten »ausgestattet« immer zum gleichen HTML-Ergebnis führt, ist es eine erhebliche Zeitersparnis, diesen erzeugten Code zwischenzuspeichern. Das lässt sich ganz einfach per Deklaration einschalten und konfigurieren.

Das Caching wird dazu in der Seite nach der Page-Anweisung mit der OutputCache-Deklaration erstellt.

Abbildung 1: Für das Caching stehen reichlich Optionen zur Verfügung

Die Kombination von verschiedenen Attributen beeinflusst letztendlich das Caching-Verhalten. Wenn eine Seite abhängig von der QueryString-Variablen ArtikelID jeweils das Datenblatt des Artikels anzeigt, reicht es nicht, die Seite nur einmal im Cache zu halten. Es muss pro Artikel eine Variante existieren. Das erreicht man mit dem Attribut VaryByParm. Damit existiert die aufgerufene Seite mehrfach im Cache.

<%@ OutputCache DiskCacheable="true" Location="ServerAndClient" 
Duration="60" NoStore="false"  VaryByParam="id" CacheProfile="myCache" %>

Die Möglichkeiten, das Caching zu beeinflussen, sind sehr umfangreich.

Attribut	Verwendung
CacheProfile	Die Cache Einstellungen werden aus einem benannten Profil (Profile) geladen. Profiles können in der Datei web.config deklariert werden.
DiskCacheable	Dieser boolesche Wert gibt an, ob die Cache-Daten auch auf die Festplatte ausgelagert werden dürfen.
Duration	Die Dauer in Sekunden, die die gecachte Seite gültig ist. Nach Ablauf der Zeit wird die ASPX-Seite neu ausgeführt und das neue Ergebnis in den Cache geladen.
Location	Sogar der Speicherort des Caches lässt sich vordefinieren. Ob dieser allerdings auch funktioniert, hängt stark von der Umgebung ab. Mögliche Werte sind: Any, Client, Downstream, Server, ServerAndClient oder None. Standardeinstellung ist Any.
NoStore	Damit wird im Header no-store gesendet, sodass Cache-Server diese Seite nicht zwischenspeichern.
Shared	Wird nur bei UserControls verwendet und gibt an, ob der Cache des UserControls über verschiedene Seiten hinweg verwendet wird.
SqlDependency	Definiert - als String - eine SQL-Abhängigkeit.
VaryByControl	Definiert anhand von Control-Namen die Abhängigkeit von diesen. Mehrere Controls werden durch Kommata getrennt.
VaryByCustom	Damit kann z. B. eine Abhängigkeit des Caches vom Browsertyp definiert werden. ASP.NET erzeugt pro Browser unterschiedliche HTML-Seiten. Die Parameter werden als Komma separierte Liste angegeben.
VaryByHeader	Damit kann der Cache in Abhängigkeit des Headers erstellt werden.
VaryByParam	Damit wird der Cache vom QueryString abhängig gemacht. Wenn es mehrere QueryString-Variablen gibt, werden diese durch Kommata getrennt angegeben.

Tabelle 1: Attribute für den Output Cache

Eines der wesentlichen neuen Attribute ist DiskCacheable. Bisher wurden gecachte Seiten immer im Arbeitsspeicher bzw. in der Auslagerungsdatei verwahrt. Nunmehr schreibt ASP.NET diese Dateien automatisch auf die Festplatte. Sogar die Größe des verwendeten Speicherplatzes und der Speicherort können definiert werden - dies allerdings nur in der web.config. Mit dem Attribut maxSizePerApp wird die Größe in MBytes angegeben.

<outputCache>
<diskCache enabled="true" maxSizePerApp="2" path="D:\cachedir"  />
</outputCache>

Listing 1: Disk Cache per web.config konfigurieren

Das Verhalten des Output Cache kann auch zur Laufzeit kontrolliert werden. Dafür besitzt das Response-Objekt eine Cache-Eigenschaft. Die Eigenschaften unterscheiden sich allerdings marginal.

Response.Cache.SetDiskCacheable(True)

Cache in web.config

Im Folgenden wird der Caching-Bereich in der Datei web.config im Detail besprochen.

Unterhalb des <caching>-Elements können vier Bereiche existieren:

Unterelement	Verwendung
cache	Damit wird die Cache-API angesprochen
outputCache	Damit wird das Disk Caching konfiguriert.
outputCacheSetting	Hier werden Cache-Profile definiert.
sqlCacheDependency	Damit werden vom SQL Server abhängige Cache-Abhängigkeiten deklariert.

Tabelle 2: Cache-Elemente in web.config

cache

Im Folgenden wird kurz ein Beispielausschnitt des Cache-Elements mit seinen möglichen Attributen gezeigt.

<cache disableDependencies="True" disableExpiration="True" disableMemoryCollection="True" percentagePhysicalMemoryUsedLimit="10" privateBytesLimit="20"></cache>

Listing 2: Beispiel cache-Element

outputCache

Das outputCache-Element aus der web.config wurde vorher schon kurz erwähnt, weil dort als Subelement die DiskCache-Einstellungen vorgenommen werden.

Darüber hinaus gibt es vier weitere Attribute, die zentral die Steuerung übernehmen. Einzig das Attribut OmitVaryStar ist nicht wirklich selbsterklärend. Dies steuert das Caching-Verhalten abhängig von der Header-Information. Der Standardwert ist false.

<outputCache omitVaryStar="True" enableFragmentCache="True" enableOutputCache="True" sendCacheControlHeader="True">

outputCacheSettings

outputCacheSettings beinhaltet keine Attribute. Das einzige Unterelement ist outputCacheProfiles.

outputCacheProfiles

Je nach Abfragehäufigkeit und Datenmenge wird Caching entsprechend eingestellt. Dabei ist Caching nicht die Lösung aller Probleme. Es kann auch welche verursachen. So sind die Daten im Cache in der Regel nicht aktuell. Es gilt also Kompromisse zu finden, die am besten auf die Bedürfnisse abgestimmt sind. In der Regel müssen unterschiedliche Seiten unterschiedlich gecacht werden, um das beste Ergebnis zu erzielen. Das kann man natürlich alles in den einzelnen Seiten festlegen. Aber die Datenmenge und die Nutzung ändern sich - und was gestern gut war, kann heute schon schlecht sein, mit der daraus folgenden Notwendigkeit: man müsste in jeder einzelnen Webseite das Caching ändern.

Viel besser ist es in solchen Fällen, Profile zu definieren. Profile sind sozusagen eine Zusammenfassung von Regeln. In der Seite wird nunmehr das Profil referenziert. Wenn sich etwas an den Regeln ändern soll, kann man diese Änderung zentral in der Datei web.config vornehmen. Im Subelement outputCacheProfiles wird per Add ein neues Profil angelegt. Die Attribute werden von Intellisense im Editor vorgegeben, sind aber die gleichen wie in der Page-outputCache-Deklaration.

<caching>
<outputCacheSettings>
    <outputCacheProfiles>
        <add name="myCache" enabled="true" duration="60"/>
    </outputCacheProfiles>
</outputCacheSettings>
</caching>

Listing 3: Ein Cache-Profil aus web.config

In der ASPX-Seite wird dann nurmehr der Name des Profiles angegeben:

<%@ OutputCache CacheProfile="myCache" %>

Ein Profil kann in einer untergeordneten web.config mit Remove wieder entfernt werden.

Fragment Caching

Diese Funktionalität ist seit ASP.NET 1.x vorhanden, wird aber der Vollständigkeit halber hier kurz beschrieben. Fragment Caching erlaubt es, Teile der Seite zwischenzuspeichern. Dies geschieht mit Hilfe von UserControls, die in die Seite einbettet werden.

Zunächst muss aber in der Datei web.config überprüft werden, ob Fragment Caching auch erlaubt ist.

enableFragmentCache="True"

Abbildung 2: Die UserControl-Zeit hinkt hinter der Seitenzeit her

Die Anwendung ist sehr einfach. Im UserControl wird das gewünschte Cache-Verhalten eingestellt:

<%@ OutputCache Duration="30" VaryByParam="None" %>

In der ASPX-Seite darf allerdings kein outputCache deklariert werden. Allerdings wird immer nur ein Teil der Seite zwischengespeichert. Genau den umgekehrten Fall erreichen Sie durch Substitution.

Substitution

Wenn sich nur ein kleiner Teil der Seite ändert und der Großteil der Seite immer gleich bleibt, bietet sich die Substitution an. Dabei wird eine Funktion angegeben, die immer ausgeführt wird und deren Rückgabe dann in die gecachte Seiten eingebaut wird.

Sie haben die Wahl, dies entweder mit dem Substitution Control oder im Response-Objekt mit der Funktion WriteSubstitution zu erledigen.

Substitution Control

Es gibt eingentlich nur ein wichtiges Attribut im Substitution-Weserver-Control, nämlich MethodName. Diesem wird der Name der aufzurufenden Funktion übergeben.

<asp:Substitution ID="Substitution1" Runat="server" MethodName="FillPlace" />

Der Inhalt des Substitution Control wird nicht gecacht.

WriteSubstitution

Das Response-Objekt beinhaltet die Funktion WriteSubstitution. Es wird ein Delegat auf die Funktion übergeben, die den dynamischen Inhalt der Seite liefert. In VB.NET wird dazu
AddressOf verwendet.

<%@ OutputCache Duration="60" VaryByParam = "none" %>
<script runat="server">
Shared Function aktuelleZeit(context As HttpContext) As String
    return DateTime.Now.ToString()
End Function
</script>
Uhrzeit: <% Response.WriteSubstitution(New HttpResponseSubstitutionCallback(AddressOf aktuelleZeit)) %>

Listing 4: Beispiel für Response.WriteSubsitution

Zeiten in der Praxis

Die erworbenen Kenntnisse werden im folgenden Beispiel auch gleich in die Praxis umgesetzt. Einer erstellten ASPX-Seite wird eine Cache-Lebensdauer von 60 Sekunden eingeräumt. Es wird die aktuelle Zeit in einem Label Control ausgegeben. Diese Anzeige kann bis zu 59 Sekunden »alt werden«. Im Substitution Control wird durch die Funktion FillPlace genau dasselbe gemacht. Die CallBack-Funktion FillPlace muss als Shared deklariert werden und einen String zurück liefern.

<%@ OutputCache DiskCacheable="true" Location="ServerAndClient" Duration="60" NoStore="false" VaryByParam="none"  %>
<script runat="server">
Shared Function FillPlace(ByVal context As HttpContext) As String
   Return "aktuell:" + Date.Now.TimeOfDay.ToString
End Function
Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
        Label1.Text = "cached:" + Date.Now.TimeOfDay.ToString
End Sub
</script>
<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" Runat="server">
    <asp:Substitution ID="Substitution1" Runat="server" MethodName="FillPlace" /><br />
    <asp:Label ID="Label1" Runat="server" Text="Label"></asp:Label>
</asp:Content>

Listing 5: Zeit und gecachte Zeit können sich unterscheiden

Den Funktionsbeweis liefert Abbildung 3. Beim ersten Aufruf sind die Zeiten noch identisch, doch schon beim nächsten Refresh sieht es anders aus. Die Zeiten unterscheiden sich deutlich, da die eine Zeitanzeige aktuell ist und die andere aus der gecachten Seite stammt.

Abbildung 3: Gecachte Seite mit »aktueller« Uhrzeit

Festplatten-Caching

Zwar sollte ein Web Server über sehr viel Arbeitsspeicher verfügen, aber von dem kann man ja bekanntermaßen nie genug haben. Falls der Speicher nicht ausreicht, ist es allemal besser, den HTML-Code der Seiten auf der Platte zu speichern, als ihn jedes Mal neu generieren zu lassen. Wenn die Anwendung neu gestartet wird, bleibt der Cache auf der Platte erhalten und die Anwendung reagiert schneller. Auch ohne Ihr Zutun ist Festplatten-Caching standardmäßig eingeschaltet. Es genügt, in der outputCache-Direktive das Attribut DiskCacheable auf true zu setzen oder auf false, um es abzuschalten.

<%@ OutputCache DiskCacheable="true" Location="ServerAndClient" 
Duration="60" NoStore="false"  VaryByParam="id"  %>

Dazu muss auch in der web.config im Bereich Cache der OutputCache konfiguriert werden. Im Unterelement diskCache kann dann zentral das Speichern auf der Festplatte deaktiviert werden. Wichtig ist es auch, den Platz zu limitieren, den der Cache benötigt. Das funktioniert mit dem Attribut maxSizePerApp und einem Wert, der den Platz in MByte definiert.

<outputCache>
    <diskCache enabled="true" maxSizePerApp="2"  />            
</outputCache>

Listing 6: In der web.config wird der Cache konfiguriert

Die Standardgröße beträgt 10 MByte. Auch der Speicherort lässt sich mit dem Attribut Path festlegen.

SQL-Abängigkeit

Wenn eine Tabelle angezeigt werden soll, reicht es in einigen Fällen nicht aus, diese einfach alle 60 Sekunden neu zu laden. Vielleicht verspüren Sie den Wunsch, den Cache zu erneuern, wenn die Daten sich geändert haben. Dabei hilft Ihnen das Attribut sqlCacheDependency.

Es gibt zwei grundlegende Verfahren, die dabei zu Anwendung kommen. Für SQL Server 7.0 und SQL Server 2000 kommt ein so genannter Poll-Mechanismus zum Einsatz. Dabei wird in einem festgelegten Intervall die Datenbank mit einer gespeicherten Prozedur (Stored Procedure) abgefragt. Wenn sich die Daten geändert haben sollten, werden diese neu geladen. Änderungen betreffen immer eine ganze Tabelle.

SQL Server 2005 verfügt für diesen Zweck über einen Benachrichtigungs-Service, der in einem »Push«-Verfahren über Änderungen an den Daten bis auf Satzebene hinunter berichtet.

Abbildung 4: Fehlermeldung bei Einsatz von sqlDependency

Konfigurieren

Um die Datenbank auf die Aufgabe vorzubereiten, den Cache zu bedienen, gibt es das Befehlszeilen-Tool aspnet_regsql. Allerdings kann man damit auch die Datenbank auf ASP.NET vorbereiten, indem man den Aufruf ohne Parameter ausführt.

Abbildung 5: Assistent zum Vorkonfigurieren der Datenbank

Im ersten Schritt wird die Datenbank vorbereitet. Dazu muss der Parameter -ed angegeben werden. Mit dem Parameter -E wird eine Trusted Connection verwendet. Der Parameter -d gibt den Namen der Datenbank an. Geben Sie folgenden Befehl an der Befehlszeile ein:

aspnet_regsql -ed -E -d northwind

Als nächstes wird aspnet_regsql mit dem Parameter -et aufgerufen, um die Tabelle anzugeben. Der Name folgt dem Parameter -t. In diesem Beispiel wird mit dem Parameter -U der Benutzername angegeben. Wenn das Passwort nicht angegeben wird, erhält man eine Eingabeaufforderung, um dieses zu erfassen.

aspnet_regsql -et -U sa  -d northwind -t customers
Password:

Will man später einmal wissen, ob alles funktioniert hat, ruft man aspnet_regsql mit dem Parameter -lt auf.

aspnet_regsql -lt -U sa  -d northwind

ACHTUNG: Achten Sie auf die korrekte und einheitliche Schreibweise von Datenbank- und Tabellennamen, da diese Namen zwischen Klein- und Großschreibung unterscheiden).

Dadurch werden im SQL Server jeweils eine Stored Procedure und eine Tabelle angelegt. Die Tabelle mit dem Namen AspNet_SqlCacheTablesForChangeNotification beinhaltet für jedes Polling einen Datensatz mit dem entsprechenden Tabellennamen.

web.config

In der Datei web.config der Webanwendung werden im Bereich Caching die Einstellungen global vorgenommen.

Dazu wird ein Unterelement SqlCacheDependency angelegt. Dort wird für jede Datenbank ein Element Databases erzeugt. In ihm können per Add-Element neue Tabellen zur Abhängigkeit hinzugefügt werden. Das Intervall, in dem ASP.NET an den Datenbankserver die Stored Procedure für das Polling absetzt, wird per pollTime in Millisekunden deklariert.

<caching>
<sqlCacheDependency enabled="true" pollTime="10000">
<databases>
   <add name="Northwind" 
   connectionStringName="AppConnectionString1"
   />
</databases>
</sqlCacheDependency>
</caching>

Listing 7: Cache Bereich aus web.config

 

Daten-Caching

Neben dem Output Caching können auch Daten zwischengespeichert werden. Diese Methode wird oft als Cache API bezeichnet, weil hauptsächlich per Code damit gearbeitet wird. Aber auch Controls wie das SqlDataSource Control machen davon Gebrauch.

Der Cache gilt immer pro Anwendung und ist deshalb mit einer Application-Variable zu vergleichen.

Sowohl der Application-Variablen als auch dem Cache-Objekt ist es egal, welche Art von Daten gespeichert wird. Der Cache dabei ist allerdings »intelligenter«. Beide brauchen übrigens bei intensiver Verwendung viel Arbeitsspeicher: Geizen Sie deshalb bei Webservern nicht mit Speicher!

Falls der zur Verfügung stehende Arbeitsspeicher doch nicht reichen sollte, werden nach einer bestimmten Logik ältere und unwichtigere Daten daraus entfernt. Eine neue Möglichkeit von ASP.NET 2.0 besteht darin, Teile des Caches auf die Festplatte auszulagern.

Eine weitere wichtige Eigenschaft von gecachten Daten ist, dass sie sich quasi selbst erneuern können, wenn bestimmte Ereignisse eintreffen. Das könnte z. B. die Änderung einer Datei sein oder das Erreichen eines bestimmten Zeitpunktes. Auch hier kommt eine neue Möglichkeit der Abhängigkeit dazu, die so genannte SQL Dependency.

Zusammenfassend gesagt handelt es sich beim Caching um eine besonders nützliche und einfache Möglichkeit, schnellere Webanwendungen zu erstellen.

SQL-Abhängigkeit

Wieder führt der einfachste Weg des Daten-Cachings über ein DataSource Control. Das SqlDataSource Control kann über das Attribut SqlCacheDependency von einer Tabelle abhängig gemacht werden. Solange die Daten in der Tabelle nicht verändert werden, wird auch kein Lesezugriff auf die Daten im SQL Server gemacht.

Natürlich muss vorher der SQL Server mit dem Tool aspnet_reqsql vorbereitet werden - wie dies in diesem Kapitel bereits beschrieben wurde.

Das DataSource Control wird in Kapitel 7 im Detail beschrieben. Vorab betrachten wir aber schon einmal die Möglichkeit des Cachings mit einem SqlDataSource Control.

Mit dem SqlDataSource Control steht ein visuelles Control für den Datenzugriff zu Verfügung. Zur Laufzeit wird dieses nicht angezeigt. Es dient einzig und allein als Brücke zu den visuellen Controls zur Darstellung. Natürlich wird dazu ein SQL-Kommando und ein Connection String benötigt.

Als nächstes wird mit dem Attribut EnableCaching das Caching für dieses Control aktiviert.

Durch zusätzliche Attribute kann die Lebensdauer der Daten gesteuert werden. Das zentrale Attribut ist hier in diesem Beispiel aber SqlCacheDependency. Damit kann die Abhängigkeit von der Datenbank und Tabelle angegeben werden, und zwar in der Form Datenbankname:Tabellenname. Achten Sie auch hier auf die korrekte Schreibweise, da diese die Groß-/Kleinschreibung berücksichtigt.

<asp:SqlDataSource ID="SqlDataSource1" Runat="server" SelectCommand="SELECT * FROM [Products]"
ConnectionString="Server=localhost;Integrated Security=True;Database=Northwind"
 EnableCaching="true"
 CacheDuration="Infinite"
 CacheExpirationPolicy="Absolute"
 SqlCacheDependency="Northwind:Products" >
</asp:SqlDataSource>

Listing 8: SqlDataSource Control mit Abhängigkeit

Darüber hinaus ist die korrekte Konfiguration des Bereiches caching in der web.config notwendig.

Cache API

Das Cache-Objekt befindet sich weitgehend unter der Kontrolle Ihres Codes. Sie können Daten laden und wieder entfernen. Mit Parametern wird die Lebensdauer gesteuert. Eine HashTable verwaltet den Schlüssel und den Wert. Wenn die Daten aus dem Cache gelesen werden, müssen sie in der Regel in den passenden Datentyp gecastet werden.

Insert

Um Daten in den Cache zu legen, können Sie Add oder Insert verwenden. Dabei ist Insert mehrfach überladen.

Cache.Insert("Cache1", Date.UtcNow)

Mit einem weiteren Parameter lässt sich eine Abhängigkeit definieren. Dazu muss ein CacheDependency-Objekt erstellt werden. In diesem wird z. B. eine Abhängigkeit von einer Datei konfiguriert. Wenn sich die Datei ändert, wird der Cache erneuert.

Dim newCachDP As New CacheDependency(Server.MapPath("web.config"), DateTime.Now)
Cache.Insert("cache2", Date.UtcNow, newCachDP)

Listing 9: Cache Dependency erstellen

Wenn Sie einen Parameter überspringen wollen, übergeben Sie einfach nothing als Wert. Etwas gewöhnungsbedürftig sind die beiden nächsten Optionen. Entweder man setzt mit dem vierten Parameter die absolute Zeit oder dem fünften Parameter eine Zeitspanne. Die Zeitspanne wird dabei als Timespan-Objekt übergeben, und bei seiner Instanzierung werden entsprechende Parameter mit Stunden, Minuten und Sekunden zur Festlegung der Zeitspanne verwendet. Allerdings muss in diesem Fall der vierte Parameter auf Date.MaxValue gesetzt sein, anderenfalls wird eine Ausnahme ausgelöst:

Cache.Insert("Cache3", Date.UtcNow, Nothing, Date.MaxValue, New TimeSpan(0, 0, 10))

Die letzte Überladung erlaubt es, eine Funktion auszuführen, wenn der Cache-Vohaltezeitraum abläuft. Das funktioniert mit Hilfe eines Delegaten auf einen Funktionsnamen:

Cache.Insert("cache4", Date.UtcNow, Nothing, _
             Date.Now.AddMinutes(1), Nothing, CacheItemPriority.Normal, _ 
             New CacheItemRemovedCallback(AddressOf RemovedCallback))

Listing 10: Einstellung der automatische »Datenpflege« im Cache-Objekt

Der Vollständigkeit halber wird hier auch noch die CallBack-Funktion aufgeführt. Diese kann verwendet werden, um die Cache-Daten erneut zu laden.

Public Sub RemovedCallback(ByVal key As String, ByVal value As Object, ByVal reason As CacheItemRemovedReason)
         ListBox1.Items.Add(Date.Now.ToString)
End Sub

Listing 11: Anwendung der Callback-Funktion

Die vierte Überladung von Insert ist identisch zum Parameterisieren mit der Add-Funktion.

Cache.Add("Cache1", Date.UtcNow, Nothing, Date.MaxValue, New TimeSpan(0, 0, 1), CacheItemPriority.Normal, Nothing)

Die Priorität kann in sechs Stufen beginnend von Low bis High deklariert werden.