nicht angemeldet
TSHello,
eine Session must Du gar nicht in einer Datenbank speichern.
Hier ging es um die Zur Session gehörenden Daten.
Die wird zwischen Server und Client ausgehandelt, der Client speichert den Keks (Cookie) mit der ausgehandelten Session ID, fertig.
Man möchte aber schon gerne sicherstellen, dass nicht aus versehen (wegen der Netzwerk-Laufzeiten) eine Racecondition entsteht und der Client sich mehrere Sessions-Identifier aushandelt (mit jedem Host, auf den seine SUB-Requests aus EINEM Hauptdokument verteilt werden)!
Die Zentralisierung und "Atomarisierung" der "Get-Session-Identifier"-Anfrage auf eine einzige Senke sollte daher sichergestellt werden.
Ausführlich hier beschrieben, solange der Client den Cookie nicht löscht und immer dieselbe ID sendet, bleibt die Sesssion bestehen.
Das ist aber im realen Leben und HTTP-Requests über Load-Balancing nicht sichergestellt, wenn man nicht genauer darüber nachdenkt, bevor man 'was zusammenbaut.
D.h., da ist es auch völlig egal welcher der Server die Response ausliefert, die Session ist davon unabhängig.
Sollte sein! Das muss aber die Programmlogik nebst Datenhaltung sicherstellen!
Erst dann, wenn es in der Session was zu speichern gibt, ein erfolgreicher Login z.B. oder ein Warenkorb, dann gehts an Speichern serverseitig. Logisch dass bei mehreren Servern diese Speicherung zentralisiert werden muss.
Wenn es nichts zu erkennen (Auth) oder zu speichern gäbe, bräuchte man gar keine HTTP-Session-Verwaltung.
Liebe Grüße
Tom S.
Es gibt nichts Gutes, außer man tut es
Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.