Tom Lane wrote:
[ . . . ]
> A general-purpose connection-reuse facility on the server end cannot
> eliminate these overheads, whereas it's trivial to avoid them within
> the context of a multi-threaded client.
PHP 4.04 does provide support for AOLServer now (which is multithreaded). I haven't had
time to play with it, and it moreover isn't certified for production use yet:
---------------------------------- snip ----------------------------------
NOTE: You should not use this module in production. PHP is not 100% stable yet in threaded mode. To increase
reliabilityenable the Global Lock by removing #define NO_GLOBAL_LOCK in main/main.c. Also don't use php_value
asit will lead to races in a sub-system (use an ini file instead).
---------------------------------- snap ----------------------------------
(from the php/sapi/aolserver/README)
But it might be the way to go forward with the connection pooling issue. Maybe the PHP
people could use some help from the Postgres developers there? I think it has been pointed
out in the context of this thread that Apache, as a multi-process server, could not
properly handle connection pooling because it's not feasible to pool connections across
several Apache children (or was that the problem?).
Regards, Frank
