| Recordsets im Application-Objekt
Wir setzen voraus, dass Sie sich mit der grundlegenden Funktionsweise des Application-Objektes auskennen - falls nicht, lesen Sie bitte die entsprechenden Abschnitte in der Onlinedokumentation des IIS nach.
Sie können im Application-Objekt nicht nur Daten, sondern auch Objekte abspeichern, diese stehen dann allen Seiten Ihrer Anwendung zur Verfügung. Wenn Sie versuchen, ein Recordset auf diese Art zu speichern, stoßen Sie möglicherweise auf folgende Fehlermeldung:
Ein Objekt, das sich dem Apartmentmodell entsprechend verhält, kann nicht zum Anwendungsobjekt hinzugefügt werden.
Dies ist wohl auch der Grund, warum vielfach rigoros davor gewarnt wird, Recordsets im Application-Objekt zu speichern. Nehmen wir uns daher etwas Zeit, diesen Sachverhalt ein wenig näher zu betrachten.
COM-Objekte, zu denen auch die ADO-Komponenten gehören, können verschiedene Threading-Modelle unterstützen - eines davon ist das Apartment-Threading Model. Ohne ins Detail gehen zu wollen, kann man sagen, dass hierbei für jede Instanz ein eigener Thread erzeugt wird. Dies klingt eigentlich nicht schlecht, da wir jedoch nur über eine Instanz verfügen, heißt dies, dass sich alle Seiten diesen einen Thread teilen müssen, wenn Sie auf das Objekt zugreifen möchten.
Lösen läßt sich diese Problem z.B. durch die Verwendung des Free-Threaded Model und es gibt sogar eine Batch-Datei (makfre15.bat) um das Threadingmodell der ADO-Komponenten anzupassen. Empfehlenswert ist dies nur, falls die Datenbankprovider dies unterstützen und thread sicher sind, bei Jet ist dies nicht der Fall, so dass wir davon keinen Gebrauch machen werden.
Wenn sich nun aber alle Seiten beim Zugriff auf unser Recordset einen Thread teilen müssen, kommt es da nicht zu Wartezeiten und zusätzlichen Problemen? Im Prinzip ist dies natürlich so, allerdings sind die Zugriffe auf unsere Datenmenge so schnell, dass uns trotzdem noch ein deutlicher Geschwindigkeitsvorteil erhalten bleibt.
Zuerst sind wir Ihnen aber noch eine Erklärung schuldig, wie Sie trotz obiger Fehlermeldung nun überhaupt das Recordset im Apllication-Objekt ablegen können - verwenden Sie hierzu die StaticObjects-Kollektion, wir möchten Ihnen an dieser Stelle gleich die komplette global.asa-Datei zeigen:
<!-- METADATA TYPE="TypeLib" NAME="Microsoft ActiveX Data Objects 2.5 Library" UUID="{00000205-0000-0010-8000-00AA006D2EA4}" VERSION="2.5" -->
<OBJECT ID="rsPlz" RUNAT="Server" SCOPE="Application" PROGID="ADODB.Recordset"></OBJECT>
<OBJECT ID="rsGebiete" RUNAT="Server" SCOPE="Application" PROGID="ADODB.Recordset"></OBJECT>
<SCRIPT LANGUAGE=VBScript RUNAT=Server>
function Disconnect(rsTmp)
set rsTmp.ActiveConnection = nothing
end function
</SCRIPT>
<SCRIPT LANGUAGE=JScript RUNAT=Server>
function InitRecordsets(){
var objCon, strCon, strSqlPlz, strSqlGebiete, objRSPlz, objRSGebiete;
try {
strCon = 'Provider=Microsoft.Jet.OLEDB.4.0;Persist Security Info=False;Data Source=' + Server.MapPath('./Gebiete.mdb');
strSqlPlz = 'SELECT Plz, Gebiet FROM Plz';
strSqlGebiete = 'SELECT ID, Name, Kurzname, Kfz FROM Gebiete';
objCon = Server.CreateObject('ADODB.Connection');
objCon.Open(strCon);
rsPlz.CursorType = 3;
rsPlz.CursorLocation = 3;
rsPlz.Open(strSqlPlz, objCon);
rsPlz(0).Properties('Optimize') = true;
rsPlz(1).Properties('Optimize') = true;
Disconnect(rsPlz);
rsGebiete.CursorType = 3;
rsGebiete.CursorLocation = 3;
rsGebiete.Open(strSqlGebiete, objCon);
rsGebiete(0).Properties('Optimize') = true;
Disconnect(rsGebiete);
objCon.Close();
} catch (e) {}
}
function DoneRecordsets(){
try {
rsPlz.Close();
rsGebiete.Close();
} catch (e) {}
}
function Application_OnStart(){
InitRecordsets();
}
function Application_OnEnd(){
DoneRecordsets();
}
</SCRIPT>
Wir initialisieren unsere Datenmengen in der Funktion Application_OnStart, so dass diese beim Start der Anwendung automatisch erzeugt werden.
Im nächsten Abschnitt möchten wir Ihnen zeigen, wie Sie die so abgelegten Recordsets in Ihren Seiten verwenden können. |
