nicht angemeldet
Hi!
Sessions sind eine Möglichkeit, Daten über mehrere Scriptinstanzen hinweg zu „erhalten“ (d.h., sie werden automatisch gespeichert und wieder geladen).
Wenn man Stammressource und AJAX auf dieselbe Session arbeiten lassen will, gehört dazu aber ein ausgeklügeltes Management, sonst bleibt die Seite hängen wegen eines Dead Locks. Der erste Request sperrt die Session, ist eventuell noch nicht fertig abgearbeitet, wenn dann schon der erste AJAX-Request eintrifft. Der muss aber warten...
Was genau willst du da als Lösung ausklügeln? Dass ein PHP-Script auf die Freigabe der Session-Datei warten muss, wenn grad eine andere Instanz sie in der Mache hat, ist so, ja. Aber das PHP-Script wird wohl kaum so geschrieben sein, dass da eine Schleife läuft, in der auf das Eintragen eines bestimmten Wertes in diese geöffnete Session gewartet wird. Denn das ist ja von vorn herein nicht möglich. Ein Dead-Lock entsteht, wenn gegenseitig auf die Freigabe(n) von Ressourcen gewartet wird. Wir können davon ausgehen, dass PHP-Scripte sich nicht wegen der Session-Datei aufhängen, höchstens verzögert werden.
Da also eine geöffnete Session nicht auf die Daten anderer Nutzungen der selben Session warten kann, sind auch die Ajax-Requests selbst nicht gegenseitig voneinander abhängig sondern ebenfalls höchstens verzögert. Das macht in der Regel nichts, wenn sie asynchron laufen.
Dead-Lock-Situationen können an anderer Stelle auftreten, beispielsweise bei mehrteiligen Datenbankaktionen, die mit explizitem Locking sich gegenseitig die Tabellen sperren. Das passiert aber nur zwischen zwei Users - inklusive dem Fall, dass der eine einmal mit Session und einmal ohne Session parallele Requests laufen hat - denn bei mehreren Requests eines Users mit Session verhindert ja schon das Schlangestehen an der Session, dass zwei DBMS-Aktionen gleichzeitig laufen. Probleme sehe ich da nur, wenn man hier versucht, die Session so schnell wie möglich wieder zu schließen, und dann noch eine Datenbankaktion startet, die von einem Dead-Lock betroffen sein könnte. Aber auch das passiert nur, wenn man explizites Locking verwendet, ohne sich schon allein deswegen Gedanken über Dead-Locks gemacht zu haben. Sich gegenseitig blockierende Datenbankabfragen, ohne dass man selbst Locking verwendet, wären ein Fehler des DBMS, gegen den man als Außenstehender nichts machen kann, weil man nicht sehen kann, welcher andere Nutzer da grad was am Laufen hat.
Auch Dateioperationen können und sollten von Locks begleitet sein. Eine einzelner Datei-Lock kann aber wie bei der Session nur zum Schlangestehen führen. Dead-Locks treten nur dann auf, wenn während eines Locks ein zweiter benötigt wird, der aber gerade von jemand anderem belegt ist, der auf die Freigabe des ersten wartet. Solange also keine zwei Locks geschachtelt werden, gibt's ein bisschen Schlangestehen und das war's.
Auf der Client-Seite können ebenfalls Dead-Locks programmiert werden, die haben dann aber genauso wie die DBMS-Dead-Locks unabhängig vom Session-Mechanismus PHPs.
Lo!