Re: Number of connections - Mailing list pgsql-php

Actually, you can't be sure.  It is quite possible to build a system in
PHP that will behave in unwanted ways if you leave transactions open
across accesses.

Apache is stateless, with a thing layer of semi-statefullness layered on
top like butter.  This is the keep alive system, which is a stock part of
the http 1.1 spec.

What happens is that when a user accesses a web page, a certain apache
backend gets associated to it for a short period of time.

The problem with keep alive is that apache has a short attention span,
since the default timeout for keep alives is 15 seconds.  Let's say user A
opens a web page with a form, and edits it for 3 minutes.  His keep alive
connection is gone.  While it is still very likely that his next request
will be serviced by the same child as the last time, there is NOT
guarantee.

Even if the user does make the changes before the timeout, or you crank up
the timeout to something huge like 30 minutes, they still aren't
guaranteed to get their own child process back, as if someone requested
access and all the other children are now tied up in keep alives or
active requests, the apache server throws the pid of all the kept alive
and waiting requests and randomly grabs one to service the request.  Poof,
keep alive gone, not the same connection.

So, you can't count on always getting your old transaction back.  What you
can do is rollback at the beginning of each script to make sure you're in
"clean space" transactionally.

For a read only type setup, where you're tossing a cursor around, you
might be able to check for the existence of one, but I don't know how.

On Sun, 18 May 2003, Raphael Bauduin wrote:

> A related mail I tried to post on the list yesterday but that I got
> back....
>
> when inserting a record in a PHP script, I sometimes use the currval
> function on the corresponding sequence to get the id of the row
> inserted.
>
> Maybe a stupid question, but I wondered if when using persisten
> connection, I could be sure there would be no problem. From the doc,
> currval  "Returns the value most recently obtained by nextval  for this
> sequence in the current server process."
>
> Can you confirm me several script using the same persistent connection
> in parallel are in separate server processes?
>
> Thanks.
>
> Raph
>
>
>
> On Sat, May 17, 2003 at 11:53:44AM -0700, David Busby wrote:
> > List,
> >     I cannot tell from the documentation if pg_pconnect() or pg_connect()
> > are really different in how the connection pool is managed.  Does anyone
> > know if that is the case?  Seems that using pg_pconnect would dictate "use a
> > pooled connection" and pg_connect is "use a pooled connection, or make a new
> > one".  On "live" apps which is better to use, seems pg_pconnect.  Thoughts?
> >
> > David Busby
> > Systems Engineer
> > busby@pnts.com
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>