Tomcat: Objekte in einer Session speichern oder im ServletContext
-
Ich habe vor kurzem irgendwo gelesen, dass man es tunlichst vermeiden sollte größere Objekte im Session Objekt zu speichern. Z.B. sollten Nutzerdaten nicht in einer Session gespeichert werden, statt desssen soll eine UserId, mit der der Benutzer eindeutigt identifiziert wird, in der Session gespeichert werden und der Rest im ServletContext, also zB Benutzername, Passwort etc.
Was ist dran und warum würde das Sinn machen?
-
tomatensalat schrieb:
Was ist dran und warum würde das Sinn machen?
Sinn macht es, auf Session-Objekte komplett zu verzichten und im Bedarfsfall gleich auf asynchrone Datenübertragung (z.B. Ajax) zu setzen.
-
Mein Anwendung ist komplett mit Ajax-Zeug gemacht (GWT). Und ehrlich gesagt, weiss ich jetzt nicht in wie fern das eine Relevanz bezueglich meiner Frage besitzt? Hast Du meine Frage ueberhaupt gelesen?
-
tomatensalat schrieb:
Hast Du meine Frage ueberhaupt gelesen?
Doch, sicher. Du meine Antwort auch? Mit einem vollständigen Verzicht auf Session-Objekte hast du z.B. dieses Problem nicht (Session-Objekte = Cookie).
-
Nun mir ist das mit den Cookies schon klar. Aber wer deaktiviert denn heute noch Cookies?
Wenn ich immer alles ueber einen Ajax Request auf dem Client speicher, dann habe ich folgende Probleme:
1. Die Verbindung zur Datenbank muss bei jedem Request neu aufgebaut werden und anschliessend am Ende wieder gedisconnected werden ( ansonsten speicher ich eine Datenbank-Objekt im Session-Objekt)
2. (ist auch eine Frage) Wie soll man denn dann ueberpruefen koennen ob ein Benutzer ueberhaupt der ist fuer den er sich ausgibt? Benutzerdaten muessen ja jedesmal auf dem Cleint gespeichert werden.
-
tomatensalat schrieb:
Nun mir ist das mit den Cookies schon klar. Aber wer deaktiviert denn heute noch Cookies?
Oh, das sind mehr als du erwartest - sehr viel mehr.
tomatensalat schrieb:
Die Verbindung zur Datenbank muss bei jedem Request neu aufgebaut werden und anschliessend am Ende wieder gedisconnected werden ( ansonsten speicher ich eine Datenbank-Objekt im Session-Objekt)
Diese Vorgehensweise, nämlich die Datenbank sofort wieder zu schließen, ist die (dringend) empfohlene.
tomatensalat schrieb:
Wie soll man denn dann ueberpruefen koennen ob ein Benutzer ueberhaupt der ist fuer den er sich ausgibt?
Mit ein wenig "Nachgedacht" sehr einfach: Generiere zum Login eine eindeutige ID (z.B. aus Zufallszahl und Tagesdatum in Sekunden). Ist Benutzer und Kennwort korrekt, werden die Werte mit der IP in eine temp. Tabelle geschrieben; die "Zahl" wird dann von Seite zu Seite 'mitgeschleppt' und kann auf jeder dieser Seiten über die temp. Tabelle geprüft werden. Weitere Verfeinerung dieser (bei uns sehr erfolgreich eingesetzten) Methode sind soeben in DEINEN Aufgabenbereich gefallen ...
tomatensalat schrieb:
Benutzerdaten muessen ja jedesmal auf dem Cleint gespeichert werden.
Nein, müssen (und dürfen) sie nicht.
-
Diese Vorgehensweise, nämlich die Datenbank sofort wieder zu schließen, ist die (dringend) empfohlene.
Warum? Ich muss dann pro Request jedes Mal eine neue Verbindung zur DB aufbauen und anschließend wieder schließen. Ist das nicht umständlicher?
Die Benutzerdaten speicher ich dann günstigerweise im ServletContext im Server in einer HashTable bzw. HashMap? Oder gibt es bessere Methoden?
-
Die Datenbankverbindung wird nicht geschlossen, das wäre viel zu ineffektiv. Die Connection wird nur an den Connection-Pool zurückgegeben. Dort steht sie dann für weitere Requests bzw. Transaktionen zur Verfügung.