problem mit eigenem session handler mysql

[easyAnfaenger26]

Hallo,
ich benutze einen eigenen session handler um meine Sessiondaten in die Mysql-Datenbank zu speichern.

Aus einem mir unerklärlichen Grund bekomme ich jetzt(merkwürdigerweise nur manchmal) einen warning: mysqli_stmt::bind_param(): invalid object or resource mysqli_stmt

//im session handler
function write($sesID,$data)
{
       $db =Singleton_DB::getInstance(); //nur eine verbindung pro client
      
       $statement= $db->stmt_init();
       $pre = 'UPDATE sessions SET lastUpdated='.(time()).',werte=? WHERE sesID=?';
       $statement->prepare($pre);
       $statement->bind_param('ss',$data,$sesID); //hier kommt der Fehler,aber nur manchmal
//... 

Die Werte "$data" und "$sesID" habe ich mir in ein log.txt ausgeben lassen und sie sind jedesmal (auch dann wenn der Fehler auftritt) okay.
Kann mir jemand sagen, wodurch dieses Verhalten ausgelöst wird?

Merci

[rkr]

Kannst du mal deine Tabelle zeigen (CREATE TABLE)?

[easyAnfaenger26]

CREATE TABLE IF NOT EXISTS `sessions` (
`sesID` char(52) NOT NULL,
`user_id` int(10) unsigned NOT NULL,
`lastUpdated` int(11) DEFAULT NULL,
`start` int(11) DEFAULT NULL,
`werte` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

ALTER TABLE `sessions`
ADD PRIMARY KEY (`sesID`);

[rkr]

lastUpdated sollte ein DATETIME sein. Sonst kannst du den Wert nicht lesen und keine datenbankspezifischen DateTime-Funktionen nutzen. Die Konvertierung zwischen timestamps und DATETIME ist ganz einfach. Gleiches gilt wohl für start. Hier kannst du ggf sogar ein TIMESTAMP mit Defaultwert CURRENT_TIMESTAMP verwenden. werte: Wusstest du, dass TEXT nur 16k Zeichen fassen kann? Sicher reicht das in den allermeisten Fällen. sesID wirkt mir mit CHAR(52) etwas zu hoch dimensioniert. CHAR ist auf jeden Fall schon mal der richtige Datentyp.

Ansonsten kann ich dir bei deinem Problem eher weniger helfen, da ich mich mit mysqli nicht auskenne. Mit PDO würde ich dein Problem jedoch eleganter lösen können.

Sind dir sessionbasierte Raceconditions bekannt? Die kannst du mit SELECT ... FOR UPDATE abfangen.

[easyAnfaenger26]

Das mit datetime ist mir klar,aber will das im moment nicht umschreiben.TEXT:Es fallen garantiert keine 16K session daten an ich verwende eine alternative session id mit 52 länge
sessionbasierte Raceconditions? sagt mir garnichts.wie geht die genaue abfrage dazu? SELECT * FROM sessions FOR UPDATE wird es ja wohl nicht sein (geht im übrigen auch nicht)

[rkr]

Das Zustandekommen von Raceconditions kann vielfältig sein. Beliebt sind Ajax und zu schnelle Abfolgen von Klicks auf einer Webseite.

Beobachtung in zeitlicher Abfolge:
Request 1 startet, Session A wird geladen.
Request 2 startet, Session A wird geladen.
Request 1 tut nichts, braucht aber lange.
Request 2 verändert Sessiondaten (Login).
Request 2 wird beendet, Sessiondaten werden geschrieben.
Request 1 wird beendet, Sessiondaten werden geschrieben.

Diagnose:
Obwohl der User den Loginvorgang ist er danach oder kurze Zeit später wieder ausgeloggt.

Lösung:
Eine Session darf immer nur von einem Request gleichzeitig bearbeitet und gespeichert werden (macht php bereits mit den Standardmethoden für dich) ODER die einzelnen Session-Array-Keys können unabhängig verändert werden und werden nur bei Veränderung wieder in die DB geschrieben (heisst, du hast für jeden SessionKey einen eigenen Datensatz; so mache ich das in einigen Projekten).

[easyAnfaenger26]

Ah,Raceconditions doch doch jetzt fällt mir das wieder ein
und ja ich nutze AJAX,ja vielleicht ist da eine zu schnelle abfolge dran schuld,weil eventuell zweimal ajax event ausgelöst wird,wo nur eins ausgelöst werden sollte..das wäre möglich.

Aber eigentlich müsste das doch egal sein,da nur lastUpdated und die "werte" verändert werden,die sesID bleibt erhalten.Und Datenverlust bei diesen Werten dürfte doch keinen solchen Fehler auslösen..?

[rkr]

Dann ließ meinen Beitrag noch mal. Genau dieser kann kann bei dir eintreten.

Hat aber nichts mit deinem eigentlichen Problem zu tun.

[easyAnfaenger26]

Ich hab den fehler gefunden: unsaubere Programmierung
Da ich dachte das ja das Programm zuende ist habe ich ein

while($db->more_results()){$db->next_result();} 

nach einem multi_query vergessen. und so die abfrage nicht sauber für weitere abfragen beendet...