Forum » Izdelava spletišč » problem PHP PDO - povezav na postgres bazo ne zapre
problem PHP PDO - povezav na postgres bazo ne zapre
jeti51 ::
Naslov je jasen - skripta se s pomočjo PDO objekta poveže na Postgres 8.1 bazo, na koncu objekt PDO postavimo na NULL, s čimer naj bi se povezava na bazo zaprla. Pa tudi sicer, če tega ne bi naredil, bi se povezava samodejno zaprla po koncu izvajanja skripte. No, dejansko je pa tako, da se povezava ne zapre oz. uniči, temveč preide v stanje CLOSE_WAIT. Sčasoma se povezave nakopičijo in strežnik prej ali slej javi napako, da je število povezav preseglo nastavljeno mejo in pomaga samo reset strežnika.
Verzija je PHP 5.1.2, operacijski sistem Windows XP (pa tudi na Linuxu enako dela), zanimivo pa je, da na mojem domačem računalniku (winXP) in pri koelgu zadeva dobro deluje, povezave pravilno zapira za sabo, pa je ista verzija baze in PHP-ja in Apacheja. Kaj bi bilo sploh za preveriti? Se mudi in če ne bo ene pametne rešitve, bo treba pač uporabiti npr. ADODB, ampak če se le da, bi se temu izognil, ker bi pomenilo nekaj več dodatnega dela.
Verzija je PHP 5.1.2, operacijski sistem Windows XP (pa tudi na Linuxu enako dela), zanimivo pa je, da na mojem domačem računalniku (winXP) in pri koelgu zadeva dobro deluje, povezave pravilno zapira za sabo, pa je ista verzija baze in PHP-ja in Apacheja. Kaj bi bilo sploh za preveriti? Se mudi in če ne bo ene pametne rešitve, bo treba pač uporabiti npr. ADODB, ampak če se le da, bi se temu izognil, ker bi pomenilo nekaj več dodatnega dela.
McAjvar ::
Samo ugibam tule ampak morda PHP, ko PDO objekt postavis na null, ne spuca dovolj dobro za seboj? Poskusi morda na "klasicen" nacin odpret povezavo, izvest kaksen stavek in jo zapret in glej, ce ti povezave tudi v tem primeru obvisijo v zraku. Morda lahko tudi v postgresql.conf nastavis belezenje connectov in disconnectov klientov in potem v log datoteki gledas, ce fases tudi disconnect. Ce ga ne, ga najbrz nekaj na strani PHPja serje. Lahko tudi pri AdoDBju najprej preveris, ce se lepo zapre vse skupaj.
"[...] the advance of civilization is nothing
but an exercise in the limiting of privacy."
- Isaac Asimov
but an exercise in the limiting of privacy."
- Isaac Asimov
jeti51 ::
ADODB povezave lepo zapre, saj zato pa sumim, da je problem v PDO. Na nekaterih računalnikih, dela, na nekaterih ne pa ne vem, ali gre za bug ali samo v kakšni nastavitvi postgresa, ki je meni trenutno neznana. Samo kot že rečeno bi prehod na ADODB pomenil nekaj dodatnega dela in bi se ne bi tega poslužil, če pa lahko morebiti problem rešim samo z eno "Kljukico v nastavitvah".
McAjvar ::
Na nekaterih računalnikih, dela, na nekaterih ne
Ali uporabljas na vseh teh racunalnikih enake verzije PHPja? Kako se obnasa, ce uporabis novejso verzijo (omenjas PHP 5.1.2, na php.net oglasujejo 5.1.4; vmesen changelog je kar obsezen, nekaj sprememb se nanasa tudi na PDO, ceprav na prvi pogled nic kaj dosti na tvoj specificen problem) ali ce tudi to ne pomaga morda se kaj novejsega - CVS verzijo? V skrajnem primeru - oddaja porocila o hroscu?
ali gre za bug ali samo v kakšni nastavitvi postgresa
Ne bi rekel, da gre za kaksno nastavitev PostgreSQLa. Ce fase komando za zaprtje povezave, jo zapre, kot si rekel da se zgodi, ce uporabis AdoDB. Torej je najbrz problem kje vmes, pri komunikaciji, da se operacija ne izvede do konca.
Ali bi v tvojem primeru prisle v postev persistent connectioni? Dokler ne najdes prave resitve bi morda vsaj malce pomagalo omiliti problem?
"[...] the advance of civilization is nothing
but an exercise in the limiting of privacy."
- Isaac Asimov
but an exercise in the limiting of privacy."
- Isaac Asimov
jeti51 ::
Včeraj smo testno namestili apache + postgres + php 5.1.4 (torej zadnaj verzija) in ni zapiralo povezav. V bistvu gre za nekaj takega, ampak zadeva datira v leto 2004, sploh pa spodaj piše, da je popravljeno. Pač nekaj s tistimi FIN paketi...
Persistent connections bi bila bolj tako-tako rešitev, sploh pa (glede na arhitekturo aplikacije) na srečo ne bi bil tako velik problem uporabiti npr. adapter design patterna. Namesto "PDO" se bo pač uporabil nek "CustomAdapter" class (serach/replace, pa je), ki bo zamaskiral ADODB class, da bo za aplikacijo na zunaj še vedno izgledal kot PDO class, pa je. Bo še najmanj dela z morebitno spremembo, če se je bo treba poslužiti.
Persistent connections bi bila bolj tako-tako rešitev, sploh pa (glede na arhitekturo aplikacije) na srečo ne bi bil tako velik problem uporabiti npr. adapter design patterna. Namesto "PDO" se bo pač uporabil nek "CustomAdapter" class (serach/replace, pa je), ki bo zamaskiral ADODB class, da bo za aplikacijo na zunaj še vedno izgledal kot PDO class, pa je. Bo še najmanj dela z morebitno spremembo, če se je bo treba poslužiti.
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
! | Postavitev Apache serverja s podporo za PHP in MySQL (strani: 1 2 3 4 5 6 7 )Oddelek: Izdelava spletišč | 252568 (27233) | miko22 |
» | Izšel PHP 5.5Oddelek: Novice / Ostala programska oprema | 5171 (3861) | technolog |
» | SQL injection napadOddelek: Informacijska varnost | 3119 (2571) | Yacked2 |
» | Raziskava o ranljivosti spletnih strani z SQL bazami podatkovOddelek: Novice / Varnost | 4917 (4253) | sverde21 |
» | [Zend Framework, PHP5] Zend_DbOddelek: Izdelava spletišč | 1835 (1622) | rokpok |