Schreiboperationen

Mit der Methode "sync" der Schnittstelle "com.ibm.websphere.servlet.session.IBMSession" können Sie manuell steuern, wann geänderte Sitzungsdaten in die Datenbank oder eine andere WebSphere Application Server-Instanz ausgelagert werden. Die Schreibfrequenzmodi "Manuelle Aktualisierung" "Ende des Service-Servlets" und "Zeitbasiert" werden zur Verfügung gestellt, um die Schreibfrequenz von Sitzungsdaten zu optimieren.

Diese Schnittstelle ist eine Erweiterung der Schnittstelle "javax.servlet.http.HttpSession". Durch Aufrufen der Methode "sync" von der Methode "service" eines Servlets aus können Sie alle Änderungen in der Sitzung an die externe Position senden. Wenn als Schreibfrequenz "Manuelle Aktualisierung" ausgewählt wurde, werden die Änderungen der Sitzungsdaten nur dann an eine externe Position gesendet, wenn die Anwendung die Methode "sync" aufruft. Wird die Methode "sync" nicht aufgerufen, gehen die Änderungen der Sitzungsdaten verloren, sobald ein Sitzungsobjekt den Servercache verlässt. Bei Auswahl der Schreibfrequenz "Ende des Service-Servlets" oder "Zeitbasiert" werden die Änderungen der Sitzungsdaten bei jedem Aufruf der Methode "sync" ausgelagert. Wird die Methode "sync" nicht aufgerufen, werden die Änderungen am Ende der Methode "service" oder entsprechend dem für die Schreibfrequenz festgelegten Zeitintervall ausgelagert.

IBMSession iSession = (IBMSession) request.getSession();
iSession.setAttribute("name", "Bob");

// Schreiben in einen externen Speicher erzwingen
iSession.sync( )

Wenn die Datenbank nicht aktiv ist oder während einer Aktualisierung der Sitzungswerte Verbindungsprobleme auftreten, unternimmt die Methode "sync" stets drei Versuche, bevor sie einen Fehler des Typs "BackedHashtable.getConnectionError" auslöst. Für jeden fehlgeschlagenen Verbindungsversuch wird eine Ausnahme des Typs "BackedHashtable.StaleConnectionException" erstellt. Falls die Datenbank während eines dieser drei Versuche geöffnet wird, werden die Sitzungsdaten aus dem Speicher in der Datenbank festgeschrieben.

Sollte die Datenbank nach den drei Versuchen immer noch nicht geöffnet sein, werden die Sitzungsdaten aus dem Speicher erst nach der nächsten Überprüfung der Sitzungsaufhebung persistent gespeichert. Die Sitzungsaufhebung wird von einem separaten Thread geprüft, der in einem Intervall von fünf Minuten ausgeführt wird. Die Daten im Speicher sind so lange konsistent, bis zwischen diesen Ereignissen eine Anforderung für die Sitzungsdaten an den Server abgesetzt wird. Wenn die Anforderung für die Sitzungsdaten beispielsweise innerhalb von fünf Minuten abgesetzt wird, werden die zuvor persistent gespeicherten Sitzungsdaten gesendet.

Sitzungen sind keine transaktionsorientierten Ressourcen. Da die Methode "sync" einem vom Client gesonderten Thread zuordnet ist, wird die erstellte Ausnahme nicht an den Client weitergegeben, der im primären Thread ausgeführt wird. Die Transaktionsintegrität der Daten kann mit Ressourcen wie Enterprise-Beans gewährleistet werden.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cprs_write_ops
Dateiname:cprs_write_ops.html