Sitzungspersistenz für Liberty konfigurieren
Wenn Sitzungsdaten auch nach einem Serverneustart oder einem nicht erwarteten Serverfehler bestehen bleiben sollen, können Sie Liberty so konfigurieren, dass die Sitzungsdaten persistent in einer Datenbank gespeichert werden. Diese Konfiguration ermöglicht die gemeinsame Nutzung derselben Sitzungsdaten durch mehrere Server und die Wiederherstellung der Sitzungsdaten im Fall einer Sitzungsübernahme.
Informationen zu diesem Vorgang
Führen Sie die folgenden Schritte aus, um Server in Liberty für die persistente Speicherung von Sitzungsdaten in einer Datenbank zu konfigurieren:
Vorgehensweise
- Definieren Sie eine Konfiguration für gemeinsames Sitzungsmanagement, die Sie in allen Servern wiederverwenden können. Sie müssen die folgenden Schritte ausführen, um die Mindestvoraussetzung zu erfüllen:
- Aktivieren Sie das Feature sessionDatabase-1.0.
- Definieren Sie eine Datenquelle:
<dataSource id="SessionDS" ... />
- Referenzieren Sie die Datenquelle in der Konfiguration der Sitzungsdatenbank.
<httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS" ... />
- Referenzieren Sie die Position des persistenten Speichers in der Konfiguration des Sitzungsmanagements.
<httpSession storageRef="SessionDB" ... />
Anmerkung: Das Attribut storageRef des Elements httpSession und das Attribut id des Elements httpSessionDatabase sind nicht verbindlich. Wenn das Feature sessionDatabase-1.0 aktiviert ist und das Element httpSessionDatabase eine gültige Datenquelle referenziert, wird die Sitzungspersistenz aktiviert, auch wenn das Attribut storageRef nicht gesetzt ist.Einzelheiten zu den Elementen httpSession und httpSessionDatabase finden Sie im Abschnitt Database Session Persistence.
Sie können beispielsweise wie folgt eine Datei mit dem Namen ${shared.config.dir}/httpSessionPersistence.xml erstellen:<server description="Demonstrates HTTP Session Persistence Configuration"> <featureManager> <feature>sessionDatabase-1.0</feature> <feature>servlet-3.0</feature> </featureManager> <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="${httpPort}"> <tcpOptions soReuseAddr="true" /> </httpEndpoint> <fileset id="DerbyFiles" includes="*.jar" dir="${shared.resource.dir}/derby/client"/> <library id="DerbyLib" filesetRef="DerbyFiles"/> <jdbcDriver id="DerbyDriver" libraryRef="DerbyLib"/> <dataSource id="SessionDS" jdbcDriverRef="DerbyDriver"> <properties.derby.client user="user1" password="password1" databaseName="${shared.resource.dir}/databases/SessionDB" createDatabase="create" /> </dataSource> <httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS"/> <httpSession storageRef="SessionDB" cloneId="${cloneId}"/> <application id="test" name="test" type="ear" location="${shared.app.dir}/test.ear"/> </server>
Anmerkung: Wenn mehrere Server für die persistente Speicherung von Sitzungsdaten in derselben Datenbank konfiguriert sind, müssen diese Server dieselbe Sitzungsmanagementkonfiguration verwenden. Alle anderen Konfigurationen werden nicht unterstützt. Es ist beispielsweise nicht möglich, dass ein Server ein mehrzeiliges Schema und ein anderer Server ein einzeiliges Schema verwendet.Das HTTP-Server-Plug-in verwendet die Klon-ID, die in den Antwort-/Anforderungsheader eingefügt wird, um die Sitzungsaffinität zwischen Anforderungen zu bewahren. Die Klon-ID verändert sich normalerweise nicht, aber in Liberty wird die Klon-ID beim ersten Start eines Servers generiert und erneut generiert, wenn der Server mit der Option --clean gestartet wird. Beim Produktionseinsatz kann durch die manuelle Zuordnung einer Klon-ID sichergestellt werden, dass die ID beständig ist und die Anforderungsaffinität ordnungsgemäß verwaltet wird. Die Klon-ID muss für jeden Server eindeutig sein und kann sich aus 8 bis 9 alphanumerischen Zeichen zusammensetzen. Sie ist in Schritt 3 angegeben.
- Schließen Sie die Konfiguration des gemeinsam genutzten Sitzungsmanagements in jeden Ihrer Server ein. Erstellen Sie beispielsweise wie folgt zwei Dateien server.xml
für die Serverinstanzen s1 und s2:
- ${wlp.user.dir}/servers/s1/server.xml
- ${wlp.user.dir}/servers/s2/server.xml
<server description="Example Server"> <include location="${shared.config.dir}/httpSessionPersistence.xml"/> </server>
Nähere Informationen hierzu finden Sie im Abschnitt Include-Element in Konfigurationsdateien verwenden.
- Geben Sie eindeutige Variablen in der Datei bootstrap.properties
jedes Servers an.
- ${wlp.user.dir}/servers/s1/bootstrap.properties
httpPort=9081 cloneId=s1
- ${wlp.user.dir}/servers/s2/bootstrap.properties
httpPort=9082 cloneId=s2
- ${wlp.user.dir}/servers/s1/bootstrap.properties
- Erstellen Sie eine Tabelle für Sitzungspersistenz, bevor Sie die Server starten.
- Wenn Sie die Standardzeilengröße, den Tabellennamen oder den Tabellenbereichsnamen ändern möchten, finden Sie im Abschnitt Database Session Persistence Einzelheiten zum Element httpSessionDatabase.
Es ist keine weitere Aktion erforderlich, wenn Ihr Server auf einem der verteilten Betriebssysteme installiert ist. Der Server erstellt die Tabelle automatisch.
- Wenn Ihr Server DB2 für die Sitzungspersistenz verwendet, können Sie den Wert für die Seitengröße erhöhen, um die Leistung für das Schreiben großer Datenmengen in die Datenbank zu optimieren.
- Synchronisieren Sie die Systemuhren aller Maschinen, die Liberty-Server hosten. Wenn die Systemuhren nicht synchronisiert werden, kann es vorzeitig zu einer Sitzungsaufhebung kommen.
- Optional: Falls erforderlich, können Sie HTTP-Sitzungen und Sicherheit in Liberty integrieren. Nachdem eine Sitzung erstellt und in einer geschützten Ressource mit aktivierter Sicherheit aufgerufen wurde, kann standardmäßig nur der ursprüngliche Eigner dieser Sitzung darauf zugreifen. Die Sitzungssicherheit (Sicherheitsintegration) ist standardmäßig aktiviert.
- Optional: Falls erforderlich, installieren und konfigurieren Sie das Web-Server-Plug-in, um Anforderungen an jeden Server, den Sie konfiguriert haben, weiterzuleiten. Die Sitzungsaffinität bleibt nur aufrechterhalten, wenn Ihre Plug-in-Konfiguration Klon-IDs enthält, die mit den Klon-IDs übereinstimmen, die in der Serverkonfiguration definiert sind.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=twlp_admin_session_persistence
Dateiname: twlp_admin_session_persistence.html