Parallel Request mit AJAX und PHP
Das Ausführen von zwei parallelen Requests mit AJAX ist nicht ganz einfach, aber machmal Notwendig. Zu beachten ist das jeder Browser nur eine gewisse Anzahl gleichzeitiger Requests an den gleichen Server ausführen kann.
Ich ging also mutig ans Werk und habe das mal ausgetestet in dem ich einen kleinen Chat implementierte (dazu später mehr). Dazu habe ich das Prototype-Framework verwendet, dessen inoffizielle Dokumentation findet man hier. Eine Request pollt für neue Nachrichten, während ein anderer auf Befehl des Benutzers nachrichten sendet. Irgendwie gingen die Nachrichten nacheinander über den Äther. Ein Schuldiger musste her! Der Schuldige ist bei mir immer im Javascript-Teil zu suchen. Vermutlich setzte das bösse Prototyp-Framework die Request in Serie. Mit dieser Vermutung machte ich auf die Suche in der Doku, im Code (zum Glück nicht so viel Code) und mit FireBug zur Laufzeit.
Und schlussendlich war dann doch nicht der Client schuld. Der "Fehler" steckte im Serverteil und wenn ich mich in PHP nicht so sicher fühlen würde hätte ich vermutlich auch früher die Kommentare in der PHP-Dokumentation gelesen. Da hatte einer zur pre-AJAX Zeit mit Frames ein ziemlich ähnliches Problem. Ich habe beim benchmarken gemerkt das session_start() ewig hängen bleibt.
Der Grund dafür ist einfach und irgendwie logisch, wird eine Session in PHP geöffnet wird sie standardmässig bis zum Abschluss des Seitenaufbaus offen gelassen. Während dieser Zeit ist es nicht möglich die Session erneut zu öffnen, der Aufruf von session_start() blockiert bis die Session vom anderen Request geschlossen wird. Das war auch der Grund warum das Seiten nacheinander abgearbeitet werden.
Die Lösung ist in meinem Fall relativ einfach. In dem lange dauernden Request greife ich nur auf eine einzige Variable lesend zu. Ich lese deshalb nach dem Öffnen der Session die Session-Variable in ein lokale Variable ein und schliesse danach die Session mit session_write_close() gleich wieder. Danach gehts auch mit zwei parallelen Request ohne Probleme und der JavaScript-Teil ist für einmal entlastet!
Ich ging also mutig ans Werk und habe das mal ausgetestet in dem ich einen kleinen Chat implementierte (dazu später mehr). Dazu habe ich das Prototype-Framework verwendet, dessen inoffizielle Dokumentation findet man hier. Eine Request pollt für neue Nachrichten, während ein anderer auf Befehl des Benutzers nachrichten sendet. Irgendwie gingen die Nachrichten nacheinander über den Äther. Ein Schuldiger musste her! Der Schuldige ist bei mir immer im Javascript-Teil zu suchen. Vermutlich setzte das bösse Prototyp-Framework die Request in Serie. Mit dieser Vermutung machte ich auf die Suche in der Doku, im Code (zum Glück nicht so viel Code) und mit FireBug zur Laufzeit.
Und schlussendlich war dann doch nicht der Client schuld. Der "Fehler" steckte im Serverteil und wenn ich mich in PHP nicht so sicher fühlen würde hätte ich vermutlich auch früher die Kommentare in der PHP-Dokumentation gelesen. Da hatte einer zur pre-AJAX Zeit mit Frames ein ziemlich ähnliches Problem. Ich habe beim benchmarken gemerkt das session_start() ewig hängen bleibt.
Der Grund dafür ist einfach und irgendwie logisch, wird eine Session in PHP geöffnet wird sie standardmässig bis zum Abschluss des Seitenaufbaus offen gelassen. Während dieser Zeit ist es nicht möglich die Session erneut zu öffnen, der Aufruf von session_start() blockiert bis die Session vom anderen Request geschlossen wird. Das war auch der Grund warum das Seiten nacheinander abgearbeitet werden.
Die Lösung ist in meinem Fall relativ einfach. In dem lange dauernden Request greife ich nur auf eine einzige Variable lesend zu. Ich lese deshalb nach dem Öffnen der Session die Session-Variable in ein lokale Variable ein und schliesse danach die Session mit session_write_close() gleich wieder. Danach gehts auch mit zwei parallelen Request ohne Probleme und der JavaScript-Teil ist für einmal entlastet!
comments
leo
@ 09.01.2007 10:36 CESTHey Harry, thanks for the hint. That's realy more that I every thougt I have to know about session handling in PHP. But this make some new problems (distributed looking, deadlooks). I write a short comment over there.
Patrick Lehnen
@ 02.02.2007 17:55 CESTDanke! genau an dieser stelle hing ich auch...
auch ich schreibe gerade einen chat unter verwendung von php, ajax und dem comet-pattern.
ich wusste bereits, dass session_start der übeltäter war, aber ich hab die ganze zeit versucht in der schleife zu prüfen ob die verbindung abgebrochen wurde um dann session_write_close() zu machen. dein beitrag hat mir die augen geöffnet. jetzt hab ich das session_write_close einfach vor die schleife mit sleeps gesetzt, weil ichs an der stelle eh nich mehr brauche. puh ;)
leo
@ 03.02.2007 01:14 CESTBitte, für genau das ist der Beitrag da. Mit dem Comet-Protokol? Find ich cool!
Machst du in deiner Abfrageschleife jeweils ein sleep und dann eine DB-Request?
add a comment
The Trackback URL to this comment is:
http://leo.freeflux.net/blog/plugin=trackback(1874).xml
This blog is gravatar enabled.
Your email adress will never be published.
Comment spam will be deleted!
There's some interesting stuff here as well: http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/