[PHP] Concurrency, sessies, singletons en mod_php / php-cgi

[jochemd]

Ik zit met een aantal vragen die zich centreren rondom de wijze waarop PHP concurrency regelt.

Op grond van de handleiding krijg ik de indruk dat het sessie model van PHP zo is dat aan het begin van een request PHP kijkt of er een session-ID is en vervolgens in het session-path kijkt of daar session-data staat die correspondeert met dat session-ID. Als dat zo is wordt die session-data ingelezen, deserialized en beschikbaar gemaakt. Aan het eind van een request wordt de session-data dan serialized en weggeschreven.
Als ik dat goed heb begrepen dan zou dat impliceren dat sessies van gelijktijdig draaiende requests niet gesynchroniseerd zijn en elkaars intermediate states niet beinvloeden. (Voorbeeld: sessie variabele X = 0, loopje in ene request dat in 10 stapjes van 1 optelt naar x = 10 zal in een ander request alleen zichtbaar zijn als 0 of 10, de stapjes 1-9 zullen nooit zichtbaar zijn in een ander request.)
Is er bekend met een referentie (anders dan de source) die deze interpretatie kan bevestigen en/of ontkrachten?

Een ander aspect van deze vraag is wat de consequenties van het wel of niet koppelen van concurrent requests zijn voor singletons. Betekent dit dat een singleton standaard niet per server is, maar per request?

En om het geheel compleet te maken de vraag of het daarbij nog verschil maakt of PHP gedraaid wordt als mod_php of als CGI applicatie en of PHP 4 en 5 nog verschillen?

[ACM]

jochemd schreef op zaterdag 01 oktober 2005 @ 13:26:
Ik zit met een aantal vragen die zich centreren rondom de wijze waarop PHP concurrency regelt.

Er wordt vziw niets geregeld. PHP draait mee met het processing- of threadingmodel van de bovenliggende omgeving. Dus als cgi-app zijn het losse processen, in apache 1.3 zijn het bij het apache-process horende omgevingen, etc. Bovendien draait elke request in een verse geheugenomgeving, de voorgaande request heeft in principe geen invloed op de nieuwe.
Waar je dat kan vinden? Ik zou het eigenlijk niet weten, het is gewoon wat ik in de loop der jaren heb afgeleid van de werking van php.

Op grond van de handleiding krijg ik de indruk dat het sessie model van PHP zo is dat aan het begin van een request PHP kijkt of er een session-ID is en vervolgens in het session-path kijkt of daar session-data staat die correspondeert met dat session-ID. Als dat zo is wordt die session-data ingelezen, deserialized en beschikbaar gemaakt. Aan het eind van een request wordt de session-data dan serialized en weggeschreven.
Als ik dat goed heb begrepen dan zou dat impliceren dat sessies van gelijktijdig draaiende requests niet gesynchroniseerd zijn en elkaars intermediate states niet beinvloeden. (Voorbeeld: sessie variabele X = 0, loopje in ene request dat in 10 stapjes van 1 optelt naar x = 10 zal in een ander request alleen zichtbaar zijn als 0 of 10, de stapjes 1-9 zullen nooit zichtbaar zijn in een ander request.)
Is er bekend met een referentie (anders dan de source) die deze interpretatie kan bevestigen en/of ontkrachten?

Wederom ervaring (en logisch denken) zorgen ervoor dat ik dit kan bevestigen. De sessie-data wordt pas aan het eind van de request weggeschreven en wijzigingen aan de $_SESSION-array worden tussendoor niet gevolgd, noch wijzigingen aan variabelen die via session_register toegevoegd zijn. Vziw uiteraard.

Een ander aspect van deze vraag is wat de consequenties van het wel of niet koppelen van concurrent requests zijn voor singletons. Betekent dit dat een singleton standaard niet per server is, maar per request?

En wederom de ervaring; voor zover ik weet is dat inderdaad per request.

En om het geheel compleet te maken de vraag of het daarbij nog verschil maakt of PHP gedraaid wordt als mod_php of als CGI applicatie en of PHP 4 en 5 nog verschillen?

Geen invloed. PHP onderhoudt geen gedeelde executie-omgeving in stand, zie het maar als zeer kort levende complete processen. De afhandeling van een request kan je vziw zien als de start, run en stop van een applicatie, waarna voor en na de run geen gegevens meer in het geheugen aanwezig blijven.
Daar bestaan overigens wel extenties voor die dat wel voor je kunnen regelen, zoals de Zend Performance Suite (of hoe dat ding tegenwoordig heet, die verandert elke nieuwe versie van naam), eAccelerator (voorheen Turck MMCache) en vergelijkbare producten. Maar ook met die oplossingen moet je expliciet dingen aan dat shared memory toevoegen, veranderen en verwijderen en mag je er vaak geen "resources" (resultsets, connections, etc) aan toevoegen. Dus voorlopig kan je geen java-like omgeving opzetten met interessante connection/object-pooling, echte singletons en dat soort dingen.

[PrisonerOfPain]

ACM schreef op zaterdag 01 oktober 2005 @ 14:15:
[Wederom ervaring (en logisch denken) zorgen ervoor dat ik dit kan bevestigen. De sessie-data wordt pas aan het eind van de request weggeschreven en wijzigingen aan de $_SESSION-array worden tussendoor niet gevolgd, noch wijzigingen aan variabelen die via session_register toegevoegd zijn. Vziw uiteraard.

Bij de manual entry van session_set_save_handler word duidelijk gemaakt dat het wegschrijven van sessie data gebeurt zodra de output stream gesloten is. Welke over het algemeen aan het eind van het script valt, tenzij je gebruik maakt van de ob_ functies om je output te regelen.

[jochemd]

ACM schreef op zaterdag 01 oktober 2005 @ 14:15:

Waar je dat kan vinden? Ik zou het eigenlijk niet weten, het is gewoon wat ik in de loop der jaren heb afgeleid van de werking van php.
(..)
Wederom ervaring (en logisch denken) zorgen ervoor dat ik dit kan bevestigen. De sessie-data wordt pas aan het eind van de request weggeschreven en wijzigingen aan de $_SESSION-array worden tussendoor niet gevolgd, noch wijzigingen aan variabelen die via session_register toegevoegd zijn. Vziw uiteraard.
(..)
En wederom de ervaring; voor zover ik weet is dat inderdaad per request.

Dat is mijn ervaring overigens ook, maar ervaringen bieden weinig garanties op forward-compatibility. Ervaringen uit het verleden bieden geen garanties voor de toekomst (Nou zijn er überhaupt nooit garanties, maar als het gedocumenteerd gedrag was dat wijzigde dan zou dat tenminste in de release notes komen. Nu is de enige manier eigenlijk testen.)

Dus voorlopig kan je geen java-like omgeving opzetten met interessante connection/object-pooling, echte singletons en dat soort dingen.

Wat me in dit geval eigenlijk wel goed uitkomt