Eine Webanwendung kann Sitzungen auf unterschiedliche Arten unterstützen. Ausgeblendete Felder in HTML-Formularen können dazu verwendet werden, Client/Server-Daten über mehrere Anforderungen hinweg beizubehalten. Alternativ dazu können Sie mithilfe von Web 2.0-Methoden, wie etwa AJAX-aktiviertes clientseitiges JavaScript, asynchrone HTTP-Anforderungen basierend auf dem Clientstatus erstellen. SQL Anywhere bietet diese zusätzlichen Funktionen zum Aufrechterhalten einer Datenbankverbindung für die exklusive Verwendung durch sitzungsbasierte HTTP-Anforderungen.

Auf alle innerhalb der HTTP-Sitzung erstellten und geänderten Verbindungsbereichsvariablen und temporäre Tabellen kann von nachfolgenden HTTP-Anforderungen, die die entsprechende SessionID angeben, zugegriffen werden. Die SessionID kann durch eine GET- oder POST HTTP-Anforderungsmethode oder innerhalb eines HTTP-Cookie-Headers angegeben werden. Beim Empfang einer HTTP-Anforderung gemeinsam mit einer SessionID-Variablen prüft der Server sein Sitzungs-Repository auf einen damit übereinstimmenden Kontext. Wenn er eine Sitzung mit übereinstimmenden Daten findet, nutzt der Server seine Datenbankverbindung zum Verarbeiten der Anforderung. Wenn sich die Sitzung in Verwendung befindet, stellt sie die HTTP-Anforderung in die Warteschlange und aktiviert sie, wenn die Sitzung freigegeben wird.

Die Methode sa_set_http_option kann zum Erstellen, Löschen und Ändern von Sitzungs-IDs verwendet werden.

HTTP-Sitzungen erfordern eine spezielle Behandlung für die Verwaltung von Sitzungskriterien. Nur eine Datenbankverbindung ist für die Verwendung durch eine bestimmte SessionID vorhanden, sodass aufeinander folgende Clientanforderungen für die betreffende SessionID vom Server serialisiert werden. Für eine SessionID können bis zu 16 Anforderungen in die Warteschlange gestellt werden. Nachfolgende Anforderungen für die angegebene SessionID werden mit einem Status des Typs 503 Service Unavailable zurückgewiesen, wenn die Sitzungswarteschlange bereits die zulässigen 16 Anforderungen enthält.

Bei der ersten Erstellung einer SessionID wird die SessionID sofort vom System registriert. Nachfolgende Anforderungen, die die SessionID ändern oder löschen, werden nur angewandt, wenn die angegebene HTTP-Anforderung beendet ist. Diese Methode führt zu einem konsistenten Verhalten, wenn die Verarbeitung von Anforderungen zu einer Zurücksetzung führt, oder wenn die Anwendung die SessionID löscht und zurücksetzt.

Die aktuelle Sitzung wird gelöscht und durch die laufende Sitzung ersetzt, wenn eine HTTP-Anforderung die SessionID ändert. Die Datenbankverbindung, die von der Sitzung in den Cache geschrieben wird, wird in den neuen Sitzungskontext verschoben, und alle Statusdaten, wie die temporären Tabellen und erstellten Variablen, werden beibehalten.

Ein vollständiges Beispiel für die Verwendung von HTTP-Sitzungen finden Sie unter Beispielverzeichnis\SQLAnywhere\HTTP\session.sql.

 Siehe auch