session speichermöglichkeiten

hello, habe gleich eine neue Frage

Hatte ja schon das Thema "unlink - Fehlerursache" aufgemacht. Das hatte ich aufgemacht, weil ich bei einem eigenen Session-Handler auf dieses Problem gestoßen bin. Dieses Thema ist so eine Art Fortsetzung von dem anderen Thema.

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.

Auf PHP: Hypertext Preprocessor sieht man oft Session-Handler mit MySQL-Datenbank. Jetzt überlege ich, ob das die beste Lösung ist. Soviel ich weiß, kann man in MySQL Tabellen vom Typ MEMORY anlegen. Dazu ein paar Fragen:

1) Wenn ich das richtig verstanden habe, legt man in MySQL die Tabelle an, die Daten liegen aber immer nur im RAM. Ist das richtig?
2) Wäre das die optimale Lösung für einen eigenen Session-Handler? Oder könnte ich dann Probleme mit dem Arbeitsspeicher bekommen?
3) Kann man beim Typ MEMORY auch mit LOCK/UNLOCK arbeiten um race-conditions zu verhindern?
4) Kann man bei MEMORY auch zeilenweise LOCKen? Also nicht nur die komplette Tabelle, sondern einen best. Datensatz?

Besonders 1) und 2) interessieren mich. 3) und 4) sollte ich hoffentlich auch noch irgendwie selbst die nächsten Tage herausfinden können. 1) deshalb, weil ich nicht weiß, wie ich kontrollieren kann, woher die Daten kommen, wenn ich einen SELECT mache.? Bei 2) befürchte ich, dass das RAM knapp wird, wenn man z. B. thumbnails erstellen möchte.

Zitat von deedee

Mein aktueller Session-Handler arbeitet mit Dateien.

Dein eigener?

Wenn's Dateien sein sollen, warum dann nicht den Default-Mechanismus von PHP nehmen? Der kümmert sich selber ums Locking.

Das "Ausbremsen" minimiert man, in dem man so früh wie möglich die Session wieder schliesst und die Daten wegschreiben lässt.

Es bleibt dann nicht bei diesem eigenen normalen Session-Handler. Da kommen dann noch Sachen in den Session-Handler dazu, damit ich schönes Login-System aufbauen kann. Ist ein Versuch. Vielleicht schmeiß ich das ganze Programm dann auch wieder gleich weg

Das frühzeitige Schließen will ich vermeiden. Bei Programmierfehlern laufe ich Gefahr dann ziemliches Chaos anzurichten, wenn ich dann versehentlich nach dem Schließen noch mit $_SESSION arbeiten sollte.

EDIT:
Habe gerade gelesen, dass row-leve-locking bei MySQL wohl nur bei dem Tabellentyp InnoDB möglich ist. Werde ich es wohl damit machen müssen. Ich schätze, das Thema hat sich dann damit wohl erledigt.

Zitat von deedee

Bei Programmierfehlern laufe ich Gefahr dann ziemliches Chaos anzurichten, wenn ich dann versehentlich nach dem Schließen noch mit $_SESSION arbeiten sollte.

Ähh, sollte man nicht eher danach streben solches "versehentliches" verwenden zu vermeiden?

File Locking dauert dir zu lange, du legst also viel Wert auf Performance.
Andererseits denkst du darüber nach, eine DB für die Daten zu verwenden. Mit der DB redest du SQL, dass du PHP-seitig zusammensetzen musst und das DBS parst es wieder. Das dürfte kaum schneller gehen als ein flock().
Memory Tables bringen dir nichts, da sie auf max_heap_table_size (default 16MB) limitiert sind und der Speicher gelöschter Tupel nicht wiederverwendet werden kann. Bei 10kB/Session könntest du < 2000 Sessions verwalten.
Greif lieber zu memcache. Damit bleiben die Daten auch ständig im RAM, wie bei Memory Tables, aber es gibt keinen Overhead durch SQL oder sonstwas.
Locking gibt es bei memcache nicht, aber du kannst einfach ein Bit setzen.

Zitat von deedee

Es bleibt dann nicht bei diesem eigenen normalen Session-Handler. Da kommen dann noch Sachen in den Session-Handler dazu, damit ich schönes Login-System aufbauen kann.

Und was reicht dir diesbezüglich an den normalen Möglichkeiten, die dir der Default-Sessionhandler bietet, nicht aus?

Mal schaun, ob ich das in wenigen Worten einigermaßen gut erklären kann. Ist etwas komplex.

Hat sich ein User eingeloggt, kann er über Formulare irgendwelche Sachen eingeben. Zum Login gibt es ein Timeout. War der User zu lange inaktiv, wird er bei seinem nächsten click zur login-Seite umgeleitet, wo er sich wieder neu anmelden muss. Wollte der User gerade eine Datei hochladen, darf die nicht verloren gehen. Nachdem er sich wieder angemeldet hat, sollen die Formulardaten ausgewertet werden. Mein Session-Handling soll sich dann auch um derartige hochgeladene Dateien kümmern. Läuft eine Session aus, soll die GC diese hochgeladenen Dateien löschen.

Wie ich das ganz genau programmieren werden, weiß ich noch nicht.

Zitat von deedee

Hat sich ein User eingeloggt, kann er über Formulare irgendwelche Sachen eingeben. Zum Login gibt es ein Timeout. War der User zu lange inaktiv, wird er bei seinem nächsten click zur login-Seite umgeleitet, wo er sich wieder neu anmelden muss.

Bei jeder Aktion Timestamp in Session ablegen, bei nächstem Zugriff Differenz zum aktuellen TS ermitteln.

Wollte der User gerade eine Datei hochladen, darf die nicht verloren gehen.

Dann ist sie direkt "beim" Hochladen irgendwo zu sichern.

Mein Session-Handling soll sich dann auch um derartige hochgeladene Dateien kümmern. Läuft eine Session aus, soll die GC diese hochgeladenen Dateien löschen.

Lediglich das erfordert extra Aufwand.

Aber da würde ich eher ein Cronjob-gesteuertes Script einsetzen, das regelmässig zu alte Dateien einfach wegputzt.

Ich komm da mit diesem row-level-locking nicht weiter

Meine open-Funktion ist leer.

In der read-Funktion versuche ich ein row-level-locking. Leider gibts ein Problem, wenn ich vor einem row-level-locking ein table-locking auf eine andere Tabelle versuche. Vereinfach dargestellt:

PHP-Code:

<?php
   // Hauptprg:
   error_reporting(E_ALL|E_STRICT);
   include './db.inc.php';              // MySQL
   $oDb=new MySQL();
   $oDb->send('set autocommit=0;');     // transaction
   $oDb->send('LOCK TABLES xy WRITE;'); // table-lock auf beliebige Tabelle
   // ab hier read-Funktion vom Session-Handler:
   $oDbResult=$oDb->send                // hier kommt eine Fehlermeldung, 
   (  'SELECT *'.                       // weil session nicht zuvor im LOCK TABLES steht
      '  FROM session '.
      'WHERE id=1 '.
      'FOR UPDATE;'                     // row-lock
   );
   $oDb->send('COMMIT;');
?>

Kann man das Problem irgendwie lösen? Ich will nicht beim LOCK TABLES auch die Tabelle session mit aufnehmen. Dann wäre ja das row-level-locking unnütz, oder?

EDIT: eigentlich frage ich mich schon seit Tagen, ob ich so ein Locking beim Session-Handler überhaupt wirklich brauche. Aber angeblich soll man das brauchen ... hat mir mal ein gewisser combie (aus einem anderen Forum) gesagt, wenn ich mich recht erinnere.

EDIT 2: Wäre es besser gewesen, dazu ein eigenes Thema im MySQL-Bereich aufzumachen??

Das war doch bestimmt der selbe combie, der sich auch hier rumtreibt.

Ob du das Locking brauchst, musst du selbst entscheiden. Ich bräuchte es nicht.

Weiß nicht, ob es der gleiche ist. Aber wäre gut. Ich weiß, der kann was

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

Ob der Combie das war, oder ist, dürfte nicht so wichtig sein....

Aber ohne Sessionlocking rennst du in Richtung "Race Conditions".
1. Willst du das?
2. Schadet dir das?
3. Kannst du das anders abwenden?

1. Willst du das?
Nö
2. Schadet dir das?
Ja
3. Kannst du das anders abwenden?
Weiß nicht. Darin bin ich gerade am verzweifeln, wie man row-locking mit table-locking kombinieren kann.
Umgekehrt (zuerst row-locking, dann table-locking) gehts nämlich.

Falls du mit permanenten DB Verbindungen arbeitest, kannst du dir damit Deadlocks einfangen. Zumindest, wenn das Script mit FatalError abschmiert.

Soweit bin ich noch gar nicht, dass ich jetzt schon an Deadlocks denke. Aber schon mal danke für diesen Tip.

Oder habe ich etwa schon ein Deadlock-Problem, wenn ich versuche, zuerst ein table-lock auf Tabelle a und dann ein row-lock auf Tabelle b zu machen?? Ich dachte, das wäre dann etwas anders.? Momentan arbeite ich aber sowieso nur normal mit mysql_connect.