Hallo
Was ist eure Meinung über die Möglichkeit SESSION auf einem DB (MySql) zu speichern?
Hier ein paar wichtige info über mein Browsergame:
-ist auf einem Shared Hosting
-benutze AJAX anfrage jeder 10 sec um eine Chat und WhoIsOnline zu aktualisieren
Ich speichere Sessions auf MySql und sehe folgende Vorteile:
-Erhöhte Sicherheit (keiner kann meine Sessions zugreifen)
-Kontrolle über WhoIsOnline
-Möglichkeit Users vom Browsergame rauszuschmeissen
Ich habe das Problem dass manchmal (sehr selten eigentlich) der Datenbank oder die Tabelle gesperrt (oder nicht zugreifbar) sind -> daher eine Fehlermeldung im Browser.
Was denkt ihr darüber?
P.S.: Also noch eine dumme Frage: wenn ein UPDATE auf eine MyISAM tabelle geführt wird, ist die gesamte tabelle gesperrt?
Sessions auf MySQL DB speichern: Vorteile und Nachteile
gepostet vor 17 Jahre, 4 Monate von DylanDog
gepostet vor 17 Jahre, 4 Monate von Agmemon
Erstmal zu Deinem P.S.: JA!
Nun zu deiner eigentlichen Frage:
Ich kenne die Session-Diskussion aus dem Rails-Umfeld. Hier gibt es viele verschiedene Ansätze für das Session-Handling. Der klassische Ansatz ist wohl der bekannteste: Speicherung der Sessions in einer Datei. Das ist einfach, allerdings nicht sehr performant und man muss dafür sorgen, dass regelmässig die veralteten Session-Dateien gelöscht werden.
Die zweite Variante ist die Speicherung der Sessions in der Datenbank. Etwas schwerer Umzusetzen, aber im Schnitt ist der Zugriff schneller, als über das Dateisystem (das zeigen zumindest unabhängige Benchmarks).
Die dritte Variante wird über memchached umgesetzt. Hier bleiben die Sessions einfach im Speicher. Der Zugriff ist super schnell, aber die Lösung hat einen kleinen Schönheitsfehler: wenn der cache verfällt, ist die Session weg. Somit hättest Du wieder das Problem mit der Fehlermeldung.
Im Moment gefällt mir eine Kombination aus Datenbank und memchached am besten: Die Session werden sowohl im Cache, als auch in der DB gehalten. Greift man lesend zu, versucht das System die Session auf dem Speicher zu holen. Bei einem Cache-Miss aus der Datenbank. Damit ist das Lesen recht schnell. Bei Änderungen an der Session, muss dann halt Cache und Db aktualisiert werden, aber das ist zu verschmerzen.
Nun zu deiner eigentlichen Frage:
Ich kenne die Session-Diskussion aus dem Rails-Umfeld. Hier gibt es viele verschiedene Ansätze für das Session-Handling. Der klassische Ansatz ist wohl der bekannteste: Speicherung der Sessions in einer Datei. Das ist einfach, allerdings nicht sehr performant und man muss dafür sorgen, dass regelmässig die veralteten Session-Dateien gelöscht werden.
Die zweite Variante ist die Speicherung der Sessions in der Datenbank. Etwas schwerer Umzusetzen, aber im Schnitt ist der Zugriff schneller, als über das Dateisystem (das zeigen zumindest unabhängige Benchmarks).
Die dritte Variante wird über memchached umgesetzt. Hier bleiben die Sessions einfach im Speicher. Der Zugriff ist super schnell, aber die Lösung hat einen kleinen Schönheitsfehler: wenn der cache verfällt, ist die Session weg. Somit hättest Du wieder das Problem mit der Fehlermeldung.
Im Moment gefällt mir eine Kombination aus Datenbank und memchached am besten: Die Session werden sowohl im Cache, als auch in der DB gehalten. Greift man lesend zu, versucht das System die Session auf dem Speicher zu holen. Bei einem Cache-Miss aus der Datenbank. Damit ist das Lesen recht schnell. Bei Änderungen an der Session, muss dann halt Cache und Db aktualisiert werden, aber das ist zu verschmerzen.
gepostet vor 17 Jahre, 4 Monate von TheUndeadable
Servus,
die Idee hatte ich mir auch überlegt, allerdings hat folgender Nachteil mich dazubewegt die Speicherung der Sessions nicht in der Datenbank durchzuführen:
- Die Notwendigkeit bei vielen Seitenaufrufen (bei dir sogar alle 10 Minuten) Informationen aus der Datenbank zu aktualisieren.
Bzgl:
> -Erhöhte Sicherheit (keiner kann meine Sessions zugreifen)
Dies hast du auch bei Sessions. Wer soll auf deine Sessions zugreifen? Bei einem ordentlichen Shared-Hosting-Anbieter hat jeder Nutzer seine eigene Session-Datenbank. Und da die Sessions auf dem Server gespeichert werden, haben auch die Clients keinen Zugriff auf die gespeicherten Infos.
Ich würde in deinem Falle die Session-Verwaltung von PHP(?) regeln lassen und die Informationen, die du über mehrere Sessions benötigst (WhoIsOnline) in der Datenbank speichern. Die Speicherung, dass Person XY gerade eine Aktion verübt hast, würde ich asynchron oder am Ende des Skriptes speichern (nachdem die Seitenausgabe erfolgt ist). Falls möglich würde ich eventuell einen von allen Skripten verwalteten Speicher nutzen.
> - Rauskicken von Benutzern
Auch da würde ich mit einer sanfteren Lösung fahren. Würde es eventuell so einstellen, dass alle Minute oder alle 5 Minuten in der Datenbank geschaut wird ob der Benutzer schon gesperrt/rausgekickt wurde. So sparst du einen Haufen an Datenbankzugriffen und kannst die Nutzer doch recht zeitnah sperren.
die Idee hatte ich mir auch überlegt, allerdings hat folgender Nachteil mich dazubewegt die Speicherung der Sessions nicht in der Datenbank durchzuführen:
- Die Notwendigkeit bei vielen Seitenaufrufen (bei dir sogar alle 10 Minuten) Informationen aus der Datenbank zu aktualisieren.
Bzgl:
> -Erhöhte Sicherheit (keiner kann meine Sessions zugreifen)
Dies hast du auch bei Sessions. Wer soll auf deine Sessions zugreifen? Bei einem ordentlichen Shared-Hosting-Anbieter hat jeder Nutzer seine eigene Session-Datenbank. Und da die Sessions auf dem Server gespeichert werden, haben auch die Clients keinen Zugriff auf die gespeicherten Infos.
Ich würde in deinem Falle die Session-Verwaltung von PHP(?) regeln lassen und die Informationen, die du über mehrere Sessions benötigst (WhoIsOnline) in der Datenbank speichern. Die Speicherung, dass Person XY gerade eine Aktion verübt hast, würde ich asynchron oder am Ende des Skriptes speichern (nachdem die Seitenausgabe erfolgt ist). Falls möglich würde ich eventuell einen von allen Skripten verwalteten Speicher nutzen.
> - Rauskicken von Benutzern
Auch da würde ich mit einer sanfteren Lösung fahren. Würde es eventuell so einstellen, dass alle Minute oder alle 5 Minuten in der Datenbank geschaut wird ob der Benutzer schon gesperrt/rausgekickt wurde. So sparst du einen Haufen an Datenbankzugriffen und kannst die Nutzer doch recht zeitnah sperren.
gepostet vor 17 Jahre, 4 Monate von DylanDog
Original von TheUndeadable
Erhöhte Sicherheit (keiner kann meine Sessions zugreifen)
Dies hast du auch bei Sessions. Wer soll auf deine Sessions zugreifen? Bei einem ordentlichen Shared-Hosting-Anbieter hat jeder Nutzer seine eigene Session-Datenbank. Und da die Sessions auf dem Server gespeichert werden, haben auch die Clients keinen Zugriff auf die gespeicherten Infos.
Das hatte ich auch gedacht, aber nachdem ich dieser Artikel gelesen habe, hatte ich mich für die aktuelle Lösung entschieden (Speicherung der Sessions in der Datenbank):
Original" target="_blank">http://www.sitepoint.com/blogs/2004/03/03/notes-on-php-session-security/
Original von Agmemon
Im Moment gefällt mir eine Kombination aus Datenbank und memchached am besten: Die Session werden sowohl im Cache, als auch in der DB gehalten. Greift man lesend zu, versucht das System die Session auf dem Speicher zu holen. Bei einem Cache-Miss aus der Datenbank. Damit ist das Lesen recht schnell. Bei Änderungen an der Session, muss dann halt Cache und Db aktualisiert werden, aber das ist zu verschmerzen.
Diese Lösung finde ich interessant...habe noch keine Ahnung wie ich sie implementieren kann aber werde mich sofort darüber informieren. Wenn es zu schwer ist,dann werde ich die Session-Verwaltung von PHP regeln lassen.
gepostet vor 17 Jahre, 4 Monate von TheUndeadable
> www.sitepoint.com/blogs/2004/03/03/notes-on-php-session-security/
Und welche der Punkte treffen nun nicht auf deine Datenbank-Cookies zu?
Punkt 1 ist bei sicheren Shared-Webservern unmöglich....
Der Rest beschränkt sich auf Angriffe auf die Session-Id, die hast du auch bei deiner Lösung.....
Die Lösung von Agmemon ist interessant und würde ich erstmal für dein Anwendungsprofil favorisieren.
Und welche der Punkte treffen nun nicht auf deine Datenbank-Cookies zu?
Punkt 1 ist bei sicheren Shared-Webservern unmöglich....
Der Rest beschränkt sich auf Angriffe auf die Session-Id, die hast du auch bei deiner Lösung.....
Die Lösung von Agmemon ist interessant und würde ich erstmal für dein Anwendungsprofil favorisieren.
gepostet vor 17 Jahre, 4 Monate von raufaser
Ich verwende bei all meinen Projekten schon immer eine eigenen Session Klasse, die die Session in der Datenbank speichert. Und damit gab es auch nie Probleme, auch nicht bei umfangreichen und gut besuchten Seiten.
Zudem gibt es immernoch die Möglichkeit in mySQL den Tabellentyp HEAP zu verwenden, womit die Tabelle im Ram angelegt wird. Da für die Sessiontabelle i.d.R. kein Auto_increment benötigt wird, sollte das problemlos möglich sein.
Funktioniert jedenfalls bei dem BG was ich derzeit programmiere bisher ohne Probleme.
Gruß,
Marc
Zudem gibt es immernoch die Möglichkeit in mySQL den Tabellentyp HEAP zu verwenden, womit die Tabelle im Ram angelegt wird. Da für die Sessiontabelle i.d.R. kein Auto_increment benötigt wird, sollte das problemlos möglich sein.
Funktioniert jedenfalls bei dem BG was ich derzeit programmiere bisher ohne Probleme.
Gruß,
Marc
gepostet vor 17 Jahre, 4 Monate von DylanDog
@Alle: Danke! jetzt habe ich verschiedene Vorschläge zur Verbesserung meiner Lösung.
Zum Schluß, Ich habe gestern abend ein bisschen recherchiert. Das Problem ist nicht neu, AJAX und sessions können zu einer "race condition" führen. Das ist genau das Problem mit meiner aktuelle Lösung (...die derzeitig kein lock benutzt).
Wer ein bisschen Zeit hat sollte folgende Blogs sich anschauen:
http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/
href="http://ajaxian.com/archives/troubles-with-asynchronous-ajax-requests-and-php-sessions" target=_blank>
http://ajaxian.com/archives/troubles-with-asynchronous-ajax-requests-and-php-sessions
href="http://www.sitepoint.com/blogs/2006/02/27/ajax-and-session-race-conditions/" target=_blank>http://www.sitepoint.com/blogs/2006/02/27/ajax-and-session-race-conditions/
Zum Schluß, Ich habe gestern abend ein bisschen recherchiert. Das Problem ist nicht neu, AJAX und sessions können zu einer "race condition" führen. Das ist genau das Problem mit meiner aktuelle Lösung (...die derzeitig kein lock benutzt).
Wer ein bisschen Zeit hat sollte folgende Blogs sich anschauen:
http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/
href="http://ajaxian.com/archives/troubles-with-asynchronous-ajax-requests-and-php-sessions" target=_blank>
http://ajaxian.com/archives/troubles-with-asynchronous-ajax-requests-and-php-sessions
href="http://www.sitepoint.com/blogs/2006/02/27/ajax-and-session-race-conditions/" target=_blank>http://www.sitepoint.com/blogs/2006/02/27/ajax-and-session-race-conditions/