[MrNiceGuy]

Ähm, ich verstehe das Zitat jetzt so, als wollten die alle Sessions in einer Datei speichern, wäre es denn nicht eher angebracht, für jede neue Session eine neue Datei anzulegen, wenn man es schon mit Dateien realisiert?

[Basti]

...absolut!

So müsstest du die Datei ja bei jedem Schreibzugriff locken und da du nicht mit den Zeiten im FS arbeiten kannst, musst du bei jedem Request eines jeden Besuchers zwangsläufig den Session-Datensatz anfassen, zumindest um den aktuellen Zeitstempel reinzusetzen. Unf für jede Änderung musst du die komplette Datei einmal Umkopieren!

Basti

[Ben]

Danke für die Kommentare.

Daraus schließe ich jetzt, dass man als klare Aussage das hier nehmen könnte:
Die Verwaltung der Session über eine Datenbank ist langsamer, als eine dateibasierte Sessionverwaltung."

Stimmt das dann nun so?

[Basti]

Nein. Die Aussage ist: Es ist schneller für jede Session eine eigene Datei zu führen, als alle Sessions in eine Datei zu schreiben, falls man die Daten überhaupt in Dateien speichern möchte.

Allerdings finde ich es wiederum unsinnig, einen eigenen Session-Handler zu schreiben, der die Sitzungsdaten in Dateien packt, denn das macht PHP ja nicht schlechter!

Natürlich sollte das ganze Session-Handling in eine Klasse, um den ganzen Sicherheitskrempel zu erledigen (z.B. SID-Wechsel beim ersten Start) und natürlich setzt man den session.save_path nicht in ein Verzeichnis, in dem andere Benutzer auf dem Server lesen und schreiben dürfen - zumindest nicht, wenn die PHP-Prozesse eines jeden Kunden nicht unter einer eigenen UID ablaufen (ich denke mal, dass das einige Provider vernachlässigen und z.B. sowohl mod_php einsetzen, als auch ein gemeinsames /tmp konfiguriert haben!)

Aber die Daten würd ich sonst nur in eine DB packen, wenn ich noch einen anderen Zugriff drauf brauche, als nur aus der Session selbst heraus auf die aktuellen Session-Daten.

BTW:
Im anderen Forum wurde das Beispiel Benutzer löschen genannt. Ich gehe davon aus, dass die Session-interne Lösung schneller ist und handhabe das von daher so, dass ich die Benutzerdaten nicht in die Session schreibe, sondern nur die UID, anhand derer ich dann bei jedem Request die Benutzerdaten aus der Datenbank lese (eben weil mir das auch zu unsicher ist, dass ich andernfalls keinen Benutzer löschen könnte, wenn der die Session am Leben hält - wobei es natürlich schon eine maximale absolute Session-Laufzeit gibt, die aber natürlich eher groß eingestellt wird).

Ansonsten:
Benchmarking. Anders wirst du das nicht rausbekommen, es sei denn, du hast hier schon Erfahrungswerte oder Messergebnisse mit ähnlicher Anordnung.

Basti

[Ben]

Danke dir für den Beitrag.
Hilft mir durchaus weiter.

[$traight-$hoota]

Zitat von Basti

Im anderen Forum wurde das Beispiel Benutzer löschen genannt. Ich gehe davon aus, dass die Session-interne Lösung schneller ist und handhabe das von daher so, dass ich die Benutzerdaten nicht in die Session schreibe, sondern nur die UID, anhand derer ich dann bei jedem Request die Benutzerdaten aus der Datenbank lese (eben weil mir das auch zu unsicher ist, dass ich andernfalls keinen Benutzer löschen könnte, wenn der die Session am Leben hält - wobei es natürlich schon eine maximale absolute Session-Laufzeit gibt, die aber natürlich eher groß eingestellt wird).

könntest du das problem nochma schildern bzw link zur anderen disk geben? oich plan nämlich net wirklich was fün problem du da beschreibst :0

[Ben]

Einfach mal die ursprüngliche Frage lesen

Zitat von Ben

da ich aktuell über einen Thread gestolpert bin, der dieses Thema ebenfalls behandelt.
http://www.zfforum.de/showthread.php?t=18

[Basti]

Das Problem ist grundsätzlich, dass alle Daten, die du einmal in die Session packst und später nicht mehr mit den persistent gespeicherten Daten abgleichst Probleme machen können. Von einfachen Race Conditions (z.B. könnten für einen Wizard Daten eingelesen werden, die ein Benutzer über mehrere Seiten hinweg bearbeitet; bevor er die Daten speichert, also von der Session wieder in den persistenten Speicher schiebt, ändert aber ein anderer Benutzer die Daten, was dann eben zu Konflikten führen kann ... wobei aber natürlich auch "normale" Requests das gleiche Konfliktpotential beinhalten) bis hin zu sicherheitskritischen Konflikten (z.B. eben, wenn Zugriffsrechte auch dann noch in der Session stehen, wenn sie dem Benutzer bereits entzogen wurden).

Basti

[pepe24]

kleiner Vorgeschmack:

im Zend Framework ist ein userdefiniertes Session-Management geplant für die version 0.8.0 bzw 0.9.0.

Da ich von Zend insgesamt recht überzeugt bin, ist das bestimmt mindestens einen Blick wert.

Gruß

[Ben]

Ja, nett. Ich nutze das ZF auch.
Zum Thema passt es hier allerdings eher nicht .. .


Aber egal.
Willkommen im Forum ..