session speichermöglichkeiten

[onemorenerd]

Warum weißt du, dass du es nicht bräuchtest?

Weil ich 3. mit Ja beantworte.

Ein Session Handler ist ein Session Handler. Wenn ich Serialisierung brauche, implementiere ich die "darüber". So bleibt der Handler austauschbar.

[combie]

Das ist doch wohl deine Sorge:

Mein aktueller Session-Handler arbeitet mit Dateien. Damit keine race-conditions stören, mache ich vor dem session_start immer einen LOCK auf eine Dummy-Datei. Das ist natürlich gar nicht toll. Bremst eine Webseite sicherlich ziemlich aus. Darum suche ich jetzt eine Alternative.

Warum bremst da irgend was aus?
Warum willst du überhaupt locken?

Mein Vorschlag:
Speichere die ganzen Dateien in einem Temp Ordner.
Per Cron oder so löscht du regelmäßig alle Dateien älter 4 H

[deedee]

Wenn ich Serialisierung brauche

Wie kommst du jetzt auf das Thema Serialisierung? Mit gehts hier jetzt um Locks.

Warum bremst da irgend was aus?

Bei der Datei-Session-Handler-Variante:
Wenn ich eine Dummy-Datei verwende, auf die ich immer einen Lock mache vor dem session_start, dann blockiere ich automatisch alle anderen Prozesse, die das auch machen wollen.

Bei der DB-Session-Handler-Variante:
Zumindest jede Member-Seite hat ein session_start. Wenn ich jetzt im Session-Handler (oder davor) einen table-lock auf die session-DB-Tabelle mache, müssen sich alle anderen Prozesse hinten anstellen. Bei row-level-locking könnte ich ein locking auf die User-spezifische Session-ID machen. Das würde dann andere User nicht aufhalten.

Cronjob-Variante:
Ist sicher eine mögliche Variante. Aber ich würde halt auch gerne lernen, wie man es mit einem Session-Handler macht.

[onemorenerd]

Wie kommst du jetzt auf das Thema Serialisierung? Mit gehts hier jetzt um Locks.

Wozu lockst du denn bitte wenn nicht um serialisierten Zugriff zu garantieren? Nur so aus Spass?

[deedee]

Hm. Verstehe ich jetzt nicht. Um die Serialisierung muss ich mich bei einem Session-Handler doch nie kümmern. Das passiert doch immer alles automatisch im Hintergrund.

Mir gehts nicht darum, schnell schnell irgendeine Lösung zu haben. Mir gehts darum zu lernen

[combie]

Aber ich würde halt auch gerne lernen, wie man es mit einem Session-Handler macht.

Der ist für sowas wenig geeignet! Du lernst also das falsche.
(meine bescheidene Ansicht)

Wenn ich eine Dummy-Datei verwende, auf die ich immer einen Lock mache vor dem session_start, dann blockiere ich automatisch alle anderen Prozesse, die das auch machen wollen.

Die können testen, ob sie dem Lock machen können, und andernfalls einfach ohne Zeitverlust dran vorbei laufen.

[deedee]

Wenn es ihnen möglich wäre daran vorbeizulaufen, würde ich doch wieder race-conditions ermöglichen, oder?

[combie]

würde ich doch wieder race-conditions ermöglichen, oder?

???
Ein Prozess lockt und löscht Dateien, alle anderen laufen unbeschadet dran vorbei! Versuchen gar nicht zu löschen!

[deedee]

Wie soll man denn dem Session-Handler klar machen, dass keine der 6 Funktionen abgearbeitet werden dürfen, wenn der Interpreter nicht locken kann und deshalb am lock vorbeiläuft?

[combie]

Was willst du auch dem SessionHandler Aufgaben aufdrücken, mit denen er nichts zu tun haben sollte!

Benutzt du einen Hammer um eine Schraube ins Gewinde zu drehen?
Fährst du mit einem Bagger in Urlaub?
Isst du deine Schuhe?

[deedee]

Nichts gegen meine Schuhe! Paniert schmecken die total lecker! *lach*
MIST! Jetzt hats mir grad nen Zahn total zerrissen. Das war die Strafe für den Lacher.

[onemorenerd]

Hm. Verstehe ich jetzt nicht. Um die Serialisierung muss ich mich bei einem Session-Handler doch nie kümmern. Das passiert doch immer alles automatisch im Hintergrund.

Automatisch passiert gar nichts. Wenn du dich nicht um die Serialisierung kümmerst, dann gibt es keine.

Was willst du eigentlich? Du willst keine Race Conditions, kein Lost Update, kein Inconsistent Read ... richtig?
Nun, genau das ist Serialisierung.

Nachtrag: Gerade fällt mir auf, dass hier vielleicht ein Missverständnis vorliegt. Ich rede nicht von serialize()!

[deedee]

Was willst du eigentlich? Du willst keine Race Conditions, kein Lost Update, kein Inconsistent Read ... richtig?
Nun, genau das ist Serialisierung.

Ich glaube, ich verstehe, was du meinst. War schon ziemlich verwirrend. Vor allem in Zusammenhang mit Sessions, wo die Daten alle serialisiert abgespeichert werden. Aber ja, genau das, was du hier meinst, das meine ich auch.

Wenn ich Serialisierung brauche, implementiere ich die "darüber"

Soviel ich weiß, muss zuerst der Session-Handler definiert werden, bevor session_start aufgerufen werden kann. Ich glaube, das wäre unnötig aufwändig, wenn ich schon vor dem Session-Handler die Session-ID aus dem Session-Cookie holen und darauf dann einen row-level-lock machen würde. Da ist es viel einfacher, sich die ID in der read-Funktion des Session-Handlers automatisch übergeben zu lassen.

Allerdings könnte man dann die Reihenfolge umdrehen, wenn man den row-lock außerhalb des Session-Handlers vornimmt. Also zuerst den row-level-lock und danach ev. irgendwelche table-locks. Dann wäre das Problem wohl gelöst. Aber glücklich wäre ich mit dieser Variante nicht, sofern ich die überhaupt hinbekomme. Muss ich mal ne Nacht drüber schlafen.

[onemorenerd]

"Darüber" heißt für mich, dass ich mich überhaupt nicht um das Locking von Sessiondaten kümmere. Ich entwerfe die Applikation so, dass ich das nicht brauche.

Mal ein Beispiel: Formular zum Bearbeiten eines Benutzerprofils.
User loggt sich ein, Session wird gestartet. User sendet Request für das Formular. Ich prüfe vor der Ausgabe, ob er eingeloggt ist. Ist er. Ich gebe das Formular aus, vorgefüllt mit seinen Profildaten.
Während ich die Ausgabe zusammenbaue, kann sich der User durch einen zweiten Request (anderes Tab) ausloggen. Das ist mir völlig egal. Ich zeige das Formular dennoch an.
Schickt der User das Formular ab, prüfe ich wieder, ob er noch eingeloggt ist. Ist er es nicht, gibt es eine Fehlermeldung. Ist er noch eingeloggt, verarbeite ich die Formulardaten. Loggt er sich während dessen aus, ist mir das wieder egal. Denn er war in der Sekunde eingeloggt, als er abgeschickt hat. Nur das zählt für mich.

In diesem Beispiel wird also immer nur einmal die Session geprüft und das Ergebnis zählt bis zum Ende des Requests. No matter what.

Das klappt so wunderbar, weil die Formulardaten nicht in die Session geschrieben werden. Aber auch das kann man handeln. Nehmen wir mal an es wäre ein mehrschrittiges Formular. User loggt sich ein, lädt die Form, füllt aus, schickt ab. Bisher alles wie gehabt. Doch nun werden die Daten noch nicht verarbeitet (z.B. in die DB geschrieben) sondern in der Session abgelegt und der zweite Teil des Formulars angezeigt. Das passiert alles in Prozess A und es passiert auf jeden Fall. Hat der User sich kurz nach der Prüfung ausgeloggt, fand das in Prozess B statt. Die GC hat die Sessiondaten vielleicht sogar schon weggeworfen. Aber am Ende von A wird $_SESSION wieder rausgeschrieben. Das Ausloggen hat damit quasi nie stattgefunden. Das ist ein Lost Update, aber eines das ich bewußt in Kauf nehme. Ich hätte mich anders entscheiden können - Ausloggen darf nicht übersehen werden. In diesem Fall hätte ich kurz vor der Ausgabe den Login-Status erneut geprüft.

Wie man sieht kümmere ich mich in keinster Weise darum, dass die Session-benutzenden Threads schon in Reihe ablaufen.
Das würde auch nur bedingt etwas bringen, denn "in der Leitung" können sich die Requests immer noch überholen. Das selbe gilt übrigens auch für DB-Anfragen. Kein mir bekanntes DBS garantiert, dass Queries in der Reihenfolge ausgeführt werden, in der sie dem DBS übergeben werden.

[asp2php]

OffTopic:

---

Ist ja lustig, wie dieser deedee euch mit seinen Schnapsideen auf Trap hält. Spätestens nach seinem 3. Posts wäre ich nicht mehr drauf eingegangen

---