session speichermöglichkeiten

Du kannst dir gar nicht vorstellen, wie lange das schon so geht. Der liebe deedee hat sich da richtig festgefressen.

Ich warte voller Spannung, ob da nicht irgendwann mal Einsicht kommt...

Wenn ich mir was vornehme, beiß ich mich auch durch
Und sollte es nicht gehen ... naja ... erzwingen kann man auch nichts.

@onemorenerd
Danke für diese ausführliche Info. Werde ich mir noch durchlesen. Aber nicht jetzt. Eine Zahnlücke hat was dagegen.

Back again.

@asp2php
Wieso glaubst du, dass das eine Schnapsidee ist?

@onemorenerd

Ausloggen darf nicht übersehen werden

Variante ohne locking:
Prozess A: session_start; Session-Daten gefunden; Daten auslesen
Prozess B: User loggt sich aus, Session wird zerstört
Prozess A: am Scriptende wird Session neu angelegt
Obwohl er sich ausgeloggt hatte, ist er lt. Session-Daten noch immer eingeloggt.

Variante mit locking:
Prozess A: session_start; Session-Daten gefunden; Daten auslesen; low-level-Lock auf Session-Daten
Prozess B: User möchte sich ausloggen; geht zum aktuellen Zeitpunkt nicht, da Session-Daten gelockt
Prozess A: Scriptende
Prozess B: User wird ausgeloggt, Session wird zerstört
User wurde sauber ausgeloggt.

Hier ginge zwar nichts kaputt, wenn man ohne locking arbeitet, aber mit locking arbeitet man sauberer. Sehe ich das richtig?

@combie:
Ich suche übrigens immer noch einen Fall, wo alles drunter und drüber geht, wenn man ohne locking arbeitet. Habe aber noch keinen gefunden.

Hier mal ein Beispiel, wo sich session_regenerate_id() und das SessionLocking in die Wolle bekommen.
Und schon hagelts die schönsten RaceConditions.

PHP-Code:

<?php
error_reporting(-1);
ini_set('display_errors',TRUE);

session_start();

//session_regenerate_id(); // erzeugt Race Conditions
//session_regenerate_id(TRUE); // erzeugt Race Conditions und Fehlermeldungen

sleep(2);

if(isset($_GET['frame']))
{
  ++$_SESSION['hitcounter'];
  echo 'Zeit: '. (time() - $_SESSION['richtzeit']) .'<br>';
  echo 'Hits: '. $_SESSION['hitcounter'] .'<br>';
  exit;
}

$_SESSION['richtzeit']  = time();
$_SESSION['hitcounter'] = 0;

?>
<frameset rows="20%,20%,20%,20%,20%">
  <frame src="?frame=<?php echo mt_rand()?>" name="test1">
  <frame src="?frame=<?php echo mt_rand()?>" name="test2">
  <frame src="?frame=<?php echo mt_rand()?>" name="test3">
  <frame src="?frame=<?php echo mt_rand()?>" name="test4">
  <frame src="?frame=<?php echo mt_rand()?>" name="test5">
</frameset>

Die Zeiten sollten im 2 Sekunden Takt in die Frames tröpfeln.

Echt interessant. Anscheinend kommt diese condition zustande, wenn man ein regenerate auf eine Session versucht, die gar nicht mehr existiert (wenn ich das richtig verstanden habe).

Also braucht man wohl im eigenen Session-Handler wirklich ein locking in der Session-start oder -read-Funktion(/Methode), sofern eine Session bereits existiert, d. h. in der MySQL-DB ein Eintrag in meiner Session-Tabelle gefunden wurde.

O. T.: Dein "wir werden alle sterben"-Link führt übrigens ins Nirvana, combie

EDIT: Damit wäre zwar geklärt, dass man mit locks arbeiten muss, leider stehe ich aber nachwievor vor dem gleichen Problem, das ich gerne irgendwie lösen würde: Wie kann man bei MySQL vor einem row-level-lock auf Tabelle A ein table-lock auf Tabelle B machen?