persistent connections, AOLserver (Was: [SQL] maybe Offtopic : PostgreSQL & PHP ?)
От | Frank Joerdens |
---|---|
Тема | persistent connections, AOLserver (Was: [SQL] maybe Offtopic : PostgreSQL & PHP ?) |
Дата | |
Msg-id | 20010418173727.A5021@rakete.joerdens.de обсуждение исходный текст |
Ответы |
Re: persistent connections, AOLserver (Was: [SQL] maybe Offtopic : PostgreSQL & PHP ?)
Re: persistent connections, AOLserver (Was: [SQL] maybe Offtopic : PostgreSQL & PHP ?) |
Список | pgsql-php |
Roberto Mello wrote: [ . . . ] > I am using PHP 4 under AOLserver/OpenNSD, which has been fully > threaded from scratch (1994) so I hope this won't be much of an issue (but > then PHP 4 still has threading problems AFAIK). Ah, very interesting indeed! I've been meaning to look into this for quite a while but never had the time to really play with it. Are you using PHP/AOLserver in a production environment? Did you have any problems, crashes, etc.? And, most importantly, how _does_ it work with persistent connections? Does AOLserver open a connection for each request/thread it creates? I think the real issue with PHP/PostgreSQL and persistent connections was to do with transactions. AFAIK the too-many-connections issue was easy to fix through some fiddling with appropriaty parameters (max_connections or something, I forget) in php.ini - it's not too well documented, you'd best just play with it and try some different options (I don't have the problem, I _am_ using persistent connections, and I can send you what I put in my php.ini if you want). The transaction issue with persistent connections was discussed a couple of weeks back here or on the php list, I am not sure. It kinda boils down to the situtation where a persistent connection is being re-used by a different apache child to the one which opened a transaction that has not yet completed, or was not completed through some error. PostgreSQL would then assume that the same client is issuing further SQL statements within the pending transaction block. This would mess things up since presumably a COMMIT WORK would be missing to complete the transactions . . . I am actually not sure what would be likely to happen, nor what the worst-case scenario might be, but it's clear that it'd be messy. I think the PHP people are working on it. The workaround was to issue a COMMIT WORK at the end of each script to close any transaction that might be pending. There was a thread about this too, a little while back. What puzzles me a little is that I've never noticed any of these issues and I am using persistent connections and transaction quite a bit. I am not using the COMMIT WORK workaround. I don't have a sense of how serious this issue might be, if it came up. AFAIK the problem is somehow rooted in the fact that PHP folks up until very recently used to have a strong MySQL bias, which doesn't (or didn't, until very recently) have proper transaction support. Hence they didn't really consider this scenario. However, what this means for the combination PHP/AOLserver/PostgreSQL is completely unclear to me, as I have no idea of what a PHP persistent connection does under AOLserver. Regards, Frank NB: I've replied to pgsql-php and not pgsql-sql because this thread seems more appropriate there.
В списке pgsql-php по дате отправления: