> a) if Apache 2 is a single-process server (as opposed to Apache 1.x which
> forks a new process for a new request)
It is a hybrid server which can be anything from one to the other.
> b) if PHP will work, or does work, with Apache 2 in this mode
It works today.
> c) how database connection pooling will work with a single http/php
> multithreaded server process
There is no database pooling.
> d) if maybe integrating php with a servlet engine as described in
> allows you to use connection pooling via jdbc or something . . . ?
> I am asking because connection pooling as it works now with persistent
> connections is pretty awkward, and leads me to look with envy on the
> Aolserver/TCL crowd . . . (I like PHP and see no reason to switch to TCL
> except for the connection pooling issue).
Why do you think you need connection pooling? Having contention for a
small set of connections is certainly not going to speed anything up. Is
it because you have license issues and are only allowed a limited number
of concurrent connections?
One easy way to deal with this today is to have a second instance of
Apache set up that has MaxClients set to the max number of database
connections you want. Then serve up scripts that need to talk to the
database from that server. A little SquidGuard rule in your
squid reverse-proxy can do this very elegantly.
There are also other options in the works for this problem. The SRM
project addresses this and when/if Apache2 ever gets stable and people
start using it, I am sure someone will write some pooling code.
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]