On Thu, Jan 25, 2001 at 04:04:24PM -0300, Martin A. Marques wrote:
[ . . . ]
> Of course. But the persistent connection are not working as the manuals say
> they should work.
It appears this riddle has been solved: From a post by Adam Lang on
pgsql-php on Dec 8:
<start quote>
Well, there's a problem with PHP's [mis]documentation. First of all,
it counts open DB connections not on per-webserver, but on
per-process/thread basis.
The default PHP config file has the limits of persistent and
non-persistent connections set to -1 (no limit)... Setting it to
some (supposedly) reasonable value (like, 50) accomplishes nothing: you
should multiply 50 by the number of webserver processes/threads. There
can be lots of them... :[
And then there comes PHP's "logic": if I can just open the new
connection, why bother reusing the old one? And thus Postgres backends
start multiplying like rabbits, eventually reaching the limit... :[
You should set a reasonable limit on number of open persistent
connections (like 1, maybe 2 or 3), only then PHP will actually reuse
them. My webserver now works with such setup and there are no more
problems with pg_pconnect().
<end quote>
[ . . . ]
> > Hmm. Say the Apache child is idle (under which cirumstances exactly does
> > it consider itself 'idle'?), receives a request for a page which
> > executes a query (because it contains php code that does). This takes a
> > while. In the meantime, while the SQL server is chugging away running
> > the query, will the Apache child not accept further http requests? How
> > does the Apache child know that it is waiting for the query to complete?
> > This is what I don't know about the mechanism.
>
> That has nothing to do with apache. If the SQL statments are well
> implemented, the second query wouldn't see any of the changes that the first
> query executed until the work is commited, and it shouldn't be able to modify
> the rows with which the first query is updating or deleting.
> But thats Postgres that doesn't let it, not the apache server, not php.
You are assuming that the Postgres backend has accurate information
about the client's identity. The "client" for the backend is the Apache
child, not the browser. The Postgres backend doesn't know anything about
web browsers. So if Apache/PHP allows a 2nd browser to connect to a
particular Apache process while it's waiting for a query to complete
that would generate information to be sent back to the first browser,
then you're in trouble. But I think it would be pretty silly for
Apache/PHP to allow that.
Regards, Frank
--
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]
