Una dintre cele mai ciudate "bugfix" PHP este că, în anumite condiții, devine imposibil să lansăm același script (sau chiar diferite scripturi) simultan de mai multe ori pe același server.
Toți programatorii mai mult sau mai puțin cunoscuți știu că PHP are un mecanism încorporat pentru stocarea datelor între cereri, numit "sesiuni".
Esența acestui lucru (dacă cineva nu știe) este sub spoilerul.
Esența sesiunilor este că, atunci când scriptul este terminat, întregul conținut al variabilei $ _SESSION este serializat automat (ambalat într-un șir) și stocat într-un fișier special într-un dosar temporar. La următoarea solicitare, acest fișier este citit automat, deserializat, iar conținutul rezultat este scris în variabila $ _SESSION.
Astfel, scenariul devine impresia că totul este scris în $ _SESSION variabilă trăiește „pentru totdeauna“, care este, nu dispare fără urmă, la sfârșitul script-ul (spre deosebire de variabile normale).
Numele fișierului temporar în care conținutul $ _SESSION variabilă este salvată este determinată de așa-numitul cod de sesiune sau session_id, sau SID. Pentru următoarea solicitare de a citi cu succes aceleași date, ID-ul sesiunii trebuie să fie undeva stocat și transmis în următoarea solicitare. De obicei, acest cookie este utilizat sau o variabilă suplimentară în cererea GET (se pare ca un fel de plus? SID = ab87d9f98e09da în adresa URL), într-o cerere POST, sau într-un cookie special, cu numele SID.
O eroare (sau mai degrabă o caracteristică) a sesiunilor standard PHP este aceea că fișierul în care sunt stocate datele sesiunii este blocat pentru acces în timp ce scriptul rulează. Acest lucru nu este întâmplător, dar este deliberat că, ca urmare a suprascrierii fișierului cu un alt script, datele sale nu se pierd.
În practică, acest lucru este exprimat prin faptul că este fizic imposibil să trimiteți două scripturi cu același identificator de sesiune pentru procesare simultană. Odată ce un script și-a început și a deschis sesiunea (folosind session_start () sau sesiune deschisă automat - există o opțiune în php.ini), astfel încât odată ce sesiunea nu mai este disponibil pentru alte script-uri (și acest lucru poate fi un al doilea exemplar al aceluiași scenariu) și încercând să deschidă o sesiune pe care o atârnă pentru o perioadă nedeterminată, și anume - până în momentul în care primul script este terminat sau are loc un timp de expirare.
Același efect exact poate fi afișat și în cazul în care dintr-un script încercați să faceți un apel la un alt script al aceluiași site. În acest caz, umflaturi cauzate de un script pentru a bloca accesul la sesiune și atârnă pe linia session_start (), un prim scenariu, care a cauzat îngheață și pentru că așteaptă un răspuns de la al doilea cauzat de un script.
Și acum, când știți ce este problema, probabil că ați înțeles deja cum să ocoliți astfel de situații. Ei bine, pentru cei care nu au ghicit, aduc o serie de decizii, sau chiar mai corect, reguli, cum să procedez, să nu cad în capcana.
Nu utilizați o sesiune decât dacă este necesar. De exemplu, dacă scriptul este destinat să ruleze din cron, nu este deloc necesar să deschideți sesiunea prin session_start (), deoarece încă nu puteți transfera modulul cookie care conține SID.
Faceți scripturile utilizând sesiunea cât mai rapidă și mai simplă posibil. Ideea este că utilizatorul nu are dorința de a da clic pe un alt link în timp ce primul se deschide. Dacă el are timp să facă al doilea scenariu se va închide de așteptare pentru sfârșitul primei executarea script-ul, iar utilizatorul va trebui să aștepte chiar mai mult până când părăsește în cele din urmă site-ului.
Încercați să nu invocați din scenariile dvs. paginile propriului site. Adică lucruri de genul
Sau, dacă este necesar, închideți sesiunea înainte de a apela, apoi deschideți-o din nou. Aproximativ astfel:
Abonați-vă la blogul meu și păstrați legătura!
Trimiteți-le prietenilor: