Ich betreibe Weblogic 10.3 lokal und habe eine Frage zu der sessionId, die es generiert. Wenn ich session.getId () drucke, sehe ich etwas, das diesem ähnelt:
BBp9TAACMTglQ2TDFAKR4tpyXg73LZDQJ2PtT9x8htG1tWY122aa! 869187422! 1308677666322
Was sind diese Ausrufezeichen und was folgt, speziell das zweite Paar:! 1308677666322? Es sieht so aus, als ob der Server es manchmal anhängt und manchmal nicht. Ich glaube, Weblogic hängt es an, wenn ich denselben Browser verwende, um mich zum zweiten Mal in meiner App anzumelden. Ist dieser Cookie irgendwie verwandt?
Betrachten Sie einige zufällig generierte Weblogic JSessionIDs aus meiner eigenen Anwendung
%Vor%und
%Vor% Wenn Sie jetzt den Teil der Sitzungs-ID nach dem ersten bemerken! d. h. 314662473 und 784323496 .
Diese Nummer ist der eindeutige Bezeichner , den Weblogic der laufenden JVM, d. h. dem laufenden Weblogic-Server, gibt.
Wenn in Ihrer Anwendung mehr als ein Server vorhanden ist, kann Weblogic Ihre Sitzung mithilfe der 9-stelligen JVM-Nummer, die Teil der Sitzungs-ID ist, an den richtigen Server zurücksenden.
Bei jedem Neustart des Weblogic-Servers wird eine neue JVM-ID generiert und verwendet, solange der Weblogic-Server ausgeführt wird. Daher haben alle Treffer auf diesem Server am Ende der Sitzungs-ID dieselbe ID.
Das Format der Sitzungs-ID lautet:
JSESSIONID = SESSION_ID! PRIMARY_JVMID_HASH! SECONDARY_JVM_HASH! CREATION_TIME
Wenn also das primäre nicht verfügbar ist, wird es versuchen, zu sekundären und zu springen, wenn Sie die Sitzungsreplikation aktiviert haben - dann können die Sitzungsdaten wiederhergestellt werden. Wenn Sie nur einen einzelnen Server auf lokalem ausführen, lautet das Format einfach
JSESSIONID = SESSION_ID! PRIMARY_JVMID_HASH! CREATION_TIME
in einigen Fällen scheint es nicht, ich habe gesehen, dass es in der Regel ein Browser abhängig ist, ob die Sitzungs-ID in der Adressleiste angezeigt wird oder nicht
WebLogic Server verwendet diese IDs, um die HTTP-Sitzungsaffinität im WebLogic Cluster In-Memory-Replikationsmodell zu verwalten.
Bei Webanwendungen mit aktivierter HTTP-Sitzungsreplikation (im Bereitstellungsdeskriptor weblogic.xml und standardmäßig deaktiviert) behält WebLogic eine primäre und eine Sicherungskopie Ihrer HTTP-Sitzung mit dem Cluster bei.
Um Cluster-Overhead zu vermeiden, analysiert das WebLogic Proxy-Plug-In (in Ihrem Web-Tier-Layer implementiert) das Sitzungscookie und leitet jede Anforderung an das WLS weiter, das Ihre primäre Kopie hostet. Bei einem Ausfall oder Overhead des verwalteten Servers, der die primäre Sitzung hostet, leitet das Proxy-Plug-In die Anforderung an die Instanz weiter, in der sich Ihre HTTP-Sitzung befindet.
Das Proxy-Plugin verfolgt eine dynamische Liste aller WebLogic Cluster-Mitglieder als Paare (JVM-IDs / IP: Ports), um jede Anfrage entsprechend umzuleiten.
Wenn Ihre App die In-Memory-Replikationsfunktion nicht aktiviert, enthält Ihr Cookie nur die JVM-ID, in der sich Ihr HTTP-Session befindet (die primäre und die eindeutige Kopie).
Tags und Links weblogic sessionid jsessionid