Verwaltung der Lebensdauer von Datenmodulen
Nach oben zu Die Struktur des Anwendungsservers
Mithilfe des Objekt-Poolings kann ein Zwischenspeicher für Datenmodule erstellt werden, den die Clients gemeinsam verwenden. Auf diese Weise werden Ressourcen gespart. Wie dies im Einzelnen realisiert wird, hängt vom Typ des bereitgestellten Datenmoduls und vom Verbindungsprotokoll ab.
Lebensdauer eines Servermoduls
Eine mit der DataSnap-Technologie erstellte Serveranwendung enthält eine Instanz von TDSServerClass. Die Eigenschaft LifeCycle für diese Instanz legt die Lebensdauer des Servermoduls fest. Die folgenden Werte sind möglich:
- Invocation
- Server
- Session (Vorgabe)
Invocation
Die Lebensdauereinstellung Invocation teilt dem DataSnap-Server mit, für jede Client-Anforderung eine neue Instanz des angegebenen Datenmoduls zu erstellen. Falls das Datenmodul Servermethoden bereitstellt, wird für jeden Methodenaufruf eine neue Instanz erstellt. Nach dem Aufruf werden Datenmodule automatisch freigegeben.
Server
Wenn die Lebensdauereinstellung Server ausgewählt wurde, erstellt der DataSnap-Server die Instanzen der Datenmodule für jeden verbundenen Client und verwendet diese wieder. Server ist nützlich, wenn das Datenmodul "client-agnostisch" sein soll, und es von jedem Client verwendet werden kann. Alle mit dieser Einstellung erstellten Datenmodule werden freigegeben, wenn der DataSnap-Server heruntergefahren wird.
Session
Die Option Session ist standardmäßig gesetzt und ist in den meisten Fällen die beste Alternative. Im Modus Session erstellt der DataSnap-Server eine Datenmodulinstanz pro Client. Das Datenmodul ist so lange vorhanden, wie der Client verbunden ist. Wenn die Verbindung zum Client beendet wird, wird die Instanz freigegeben. Dadurch erhalten Sie detaillierte Informationen, die Sie während der Sitzung verwenden können.
Pooling von Datenmodulen (COM)
Wenn Sie ein transaktionales Datenmodul erstellen, das in Verbindung mit COM+ installiert wird, können Sie den Anwendungsserver mithilfe des COM+ Component Manager als im Pool verwaltetes Objekt installieren.
Wird die Verbindung über TWebConnection eingerichtet, können Sie die Vorteile des Objekt-Poolings auch für andere Anwendungsserver als transaktionale Datenmodule nutzen. Bei diesem zweiten Typ des Objekt-Poolings ist die Anzahl der Datenmodulinstanzen beschränkt. Dadurch wird die Anzahl der aufrechtzuerhaltenden Datenbankverbindungen ebenso wie der Bedarf an anderen vom Datenmodul benötigten Ressourcen begrenzt.
Die Web-Serveranwendung (die Aufrufe an das Remote-Datenmodul übergibt) leitet eingehende Client-Anforderungen an das erste im Pool verfügbare Remote-Datenmodul weiter. Falls kein Remote-Datenmodul verfügbar ist, wird eines erstellt (sofern die von Ihnen angegebene maximale Anzahl von Datenmodulinstanzen noch nicht erreicht ist). Dies stellt einen Kompromiss zwischen der Vermittlung aller Clients über eine einzige Instanz des Remote-Datenmoduls (die einen Engpass bilden kann) und dem Erstellen einer separaten Instanz für jede Client-Verbindung (was einen Ressourcenmangel verursachen kann) dar.
Um einen Ressourcenmangel zu verhindern, werden im Pool verwaltete Remote-Datenmodule, die längere Zeit keine Client-Anforderungen empfangen haben, automatisch freigegeben.
Um eine Objektverwaltung mit einer Webverbindung (HTTP) einzurichten, muss das Remote-Datenmodul die Methode UpdateRegistry überschreiben. Rufen Sie in der überschriebenen Methode RegisterPooled auf, wenn das Remote-Datenmodul registriert wird und UnregisterPooled, wenn die Registrierung des Remote-Datenmoduls aufgehoben wird.
Für diese beiden Methoden muss das Remote-Datenmodul statuslos sein. Der Grund dafür ist, dass eine einzelne Instanz potenziell Anforderungen von mehreren Clients behandeln kann. Wenn die Instanz von persistenten Statusinformationen abhängig ist, könnten sich Clients gegenseitig behindern. Informationen dazu, wie Sie die Statuslosigkeit von Remote-Datenmodulen gewährleisten, finden Sie unter Statusinformationen in Datenmodulen unterstützen.