[PHP] Persistent connections

[Nibin V M]

Hello,

I have been reading docs and many are telling that persistent connections
are kept open indefinitely. But I found in PHP docs that it will not close
after script execution like requesting  a page; so should it close after
the request is over?

So when exactly a persistent connection should close?

Please advice.

-- 
Regards

Nibin.

Re: [PHP] Persistent connections

[Stuart Dallas]

On 25 Oct 2013, at 12:51, Nibin V M  wrote:

> Thank you for the quick response Stuart...one more doubt..at 
> http://php.net/manual/en/features.persistent-connections.php they states
> 
> =
> This means that when the same client makes a second request to the server, it 
> may be served by a different child process than the first time. When opening 
> a persistent connection, every following page requesting SQL services can 
> reuse the same established connection to the SQL server
> =
> 
> Is the persistent connection pool is re-used between apache child processes ? 

No, connections are not shared between PHP processes. Nothing is shared between 
PHP processes.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/


> On Fri, Oct 25, 2013 at 3:54 PM, Stuart Dallas  wrote:
> On 25 Oct 2013, at 11:10, Nibin V M  wrote:
> 
> > I have been reading docs and many are telling that persistent connections
> > are kept open indefinitely. But I found in PHP docs that it will not close
> > after script execution like requesting  a page; so should it close after
> > the request is over?
> >
> > So when exactly a persistent connection should close?
> >
> > Please advice.
> 
> A persistent connection is closed when the PHP process ends, or it gets 
> disconnected by the server-side or due to a network error. Attempting to 
> explicitly close a persistent connection will do nothing without complaining.
> 
> -Stuart
> 
> --
> Stuart Dallas
> 3ft9 Ltd
> http://3ft9.com/
> 
> 
> 
> -- 
> Regards
> 
> Nibin.
> 
> http://TechsWare.in


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Persistent connections

[Stuart Dallas]

On 25 Oct 2013, at 11:10, Nibin V M  wrote:

> I have been reading docs and many are telling that persistent connections
> are kept open indefinitely. But I found in PHP docs that it will not close
> after script execution like requesting  a page; so should it close after
> the request is over?
> 
> So when exactly a persistent connection should close?
> 
> Please advice.

A persistent connection is closed when the PHP process ends, or it gets 
disconnected by the server-side or due to a network error. Attempting to 
explicitly close a persistent connection will do nothing without complaining.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Persistent connections with mysql_pconnect()

[CPT John W. Holmes]

> no, not at all... but there is a time and a place, and i don't think you
> should use pconnect just because you don't want to an include at the top
of
> every page.

You still have to call pconnect() on every page if you use it. It doesn't
leave it open for other requests, it leaves it open within the web server
program. pconnect() is only useful on certain OS using certain web servers.
Read the manual page on mysql_pconnect() for more information.

---John Holmes...

> - Original Message -
> From: "John Hicks" <[EMAIL PROTECTED]>
> To: "php" <[EMAIL PROTECTED]>
> Sent: Tuesday, March 25, 2003 5:11 PM
> Subject: [PHP] Persistent connections with mysql_pconnect()
>
>
> > On Tuesday 25 March 2003 09:02 am, "skate" <[EMAIL PROTECTED]> wrote:
> > > leaving the connection open creates security questions,
> > > and also leaves resources open, what if a user closes his
> > > browser window, how do you know to close the connection?
> >
> > So are you saying that persistent connections  [ i.e. mysql_pconnect() ]
> > should never be used?
> >
> > > if you really want to make it simple, you can edit your
> > > php.ini to have the username and password as default in
> > > there, but again, this can be a security risk.
> > >
> > > i'm afraid the best way is to include connection code on
> > > every page...
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Persistent connections with mysql_pconnect()

[skate]

no, not at all... but there is a time and a place, and i don't think you
should use pconnect just because you don't want to an include at the top of
every page.

- Original Message -
From: "John Hicks" <[EMAIL PROTECTED]>
To: "php" <[EMAIL PROTECTED]>
Sent: Tuesday, March 25, 2003 5:11 PM
Subject: [PHP] Persistent connections with mysql_pconnect()


> On Tuesday 25 March 2003 09:02 am, "skate" <[EMAIL PROTECTED]> wrote:
> > leaving the connection open creates security questions,
> > and also leaves resources open, what if a user closes his
> > browser window, how do you know to close the connection?
>
> So are you saying that persistent connections  [ i.e. mysql_pconnect() ]
> should never be used?
>
> > if you really want to make it simple, you can edit your
> > php.ini to have the username and password as default in
> > there, but again, this can be a security risk.
> >
> > i'm afraid the best way is to include connection code on
> > every page...
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Persistent connections with mysql_pconnect()

[John Hicks]

On Tuesday 25 March 2003 09:02 am, "skate" <[EMAIL PROTECTED]> wrote:
> leaving the connection open creates security questions,
> and also leaves resources open, what if a user closes his
> browser window, how do you know to close the connection?

So are you saying that persistent connections  [ i.e. mysql_pconnect() ]
should never be used?

> if you really want to make it simple, you can edit your
> php.ini to have the username and password as default in
> there, but again, this can be a security risk.
>
> i'm afraid the best way is to include connection code on
> every page...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] persistent connections

[Chris Knipe]

Lo all,

Is there anyway to "manage" persistent connections to MySQL?

I've started using them on various of my sites (mysql_pconnect instead of
mysql_connect - as in the documentation), but after a few hours, I notice
that the connections just keeps on getting more and more and more.

Eventually, the entire server crawls to a standstill and I have to restart
mysql to speed up the system...

Any ideas?


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Persistent connections and transactions

[Nuno Silva]

Frank Joerdens wrote:

> On Fri, Jan 26, 2001 at 11:01:14AM +, Nuno Silva wrote:
> [ . . . ]
> 
>> i ran across this transaction problem vs. persistent conn in pgsql some time ago.
>> 
>> I found two workaround methods:
>> - don't use persistent conn's :-) or;
>> - start every conn with the usual pg_pconnect and then query a rollback to the 
>server:
>> $query="ROLLBACK work;"
>> 
>> (this will kill any supposed transaction in ABORT STATE that some child had left).
>> 
>> postgres don't support nested transactions (yet), but when it does maybe you should 
>add multiple "ROLLBACK WORK;" queries :-)
> 
> 
> Ah. Very cool. What I _still_ don't quite understand, though, is _how_
> exactly this situation could come about. And what the worst case would
> be. What if you don't kill the transaction in ABORT STATE?
> 
> Ta, Frank
> 

Hi,
this happens because pg_pconnect don't know about transactions. If some 
transaction reach ABORT and for some reason the script never makes it to 
COMMIT or ABORT queries the postgresql backend will be _always_ in ABORT 
STATE.

The problem is present in several combinations... for instance: in mysql 
you could make the connection with one user to database X. While logged 
in you could change to database Y This database backend will be in 
database Y after that! Even if you persistent_connect with the original 
parameters!

This is because the backend is never terminated and retains the last 
state, being it a ABORT STATE or another DB... :)

queriing "ROLLBACK WORK;" right after the conect is my best shot at this 
one.

Regards,
Nuno Silva




-- 
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]

Re: [PHP] Persistent connections and transactions

[Terrence Chay]

on 1/25/01 11:49 AM, Frank Joerdens at [EMAIL PROTECTED] wrote:

> 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:

> 
> 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().
> 

This sounds very confusing. Does anyone know how pconnects are pooled?
For instance this post implies that pconnects might be pooled on a per httpd
child process which would be silly as hell because httpd processes surely
"spawn like rabbits" and all of them would eventually cycle to a web page
that would generate a persistant connection.

How are pconnects released into the pool? If the former case there is no
pool so no reason to release. In the latter case, there should be a
procedure I could call (like pg_pclose()?) which would not close the
connection but simply release it back into a pool for another pconnect() of
a different httpd to call. This could especially be useful for long-running
scripts.

How are pconnects terminated? Is there a time to live on them? Are they
never dying unless the child dies? The load on most web servers often varys
by a factor of 8 during the day and 2 between weekends and weekdays. Without
pconnect termination, one would accumulate a lot of idle persistent
connections. Ideally, PHP would manage it.

It's not like the pconnect() HAS to be on a per-child business. In
theory pconnects could be put into a shared memory segment and pooled. A
time to live of 30 minutes and configurable in php.ini would handle most web
server/db interaction and ensure that you don't have say 115 open
connections to the database with only 4 being used at a time.

I don't know how PHP is programmed or how the PosgreSQL extension was
made so I really have no clue here.

terry 

-- 
terry chay, Director of Engineering, 
QIXO /kick.so/ - Integrating Many Travel Web Sites Into One
W: 1.408.394-8102 F:1.408.516.9090M: 1.408.314.0717
E-Mail:  ICQ: 16069322
PGP Fingerprint: 6DCF 1634 547C 935D 4912  2A44 A4A2 79AB DFFF F110 


-- 
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]

Re: [PHP] Persistent connections and transactions

[Frank Joerdens]

On Fri, Jan 26, 2001 at 11:01:14AM +, Nuno Silva wrote:
[ . . . ]
> i ran across this transaction problem vs. persistent conn in pgsql some time ago.
> 
> I found two workaround methods:
> - don't use persistent conn's :-) or;
> - start every conn with the usual pg_pconnect and then query a rollback to the 
>server:
> $query="ROLLBACK work;"
> 
> (this will kill any supposed transaction in ABORT STATE that some child had left).
> 
> postgres don't support nested transactions (yet), but when it does maybe you should 
>add multiple "ROLLBACK WORK;" queries :-)

Ah. Very cool. What I _still_ don't quite understand, though, is _how_
exactly this situation could come about. And what the worst case would
be. What if you don't kill the transaction in ABORT STATE?

Ta, 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]

Re: [PHP] Persistent connections and transactions

[Nuno Silva]

Frank Joerdens wrote:

> On Thu, Jan 25, 2001 at 05:10:54PM -0300, Martin A. Marques wrote:
> [ . . . ]
> 
>> OK, lets see if we can understand what each other is saying (maybe I'm not 
>> getting your point here).
>> Lets say browser A connects to the apache server, to a page using php code. 
>> Lets say the code is OK (no bugs). Apache opens a persistent connection to 
>> the database and starts executing the queries. Now the connection between the 
>> apache server and the web browser doesn't close until the queries are all 
>> finished and the output is send back to the browser.
>> Now, how about if browser B connects to the apache server just in the middle 
>> of the execution of the queries that browser A asked for?
>> Well, the connection between Browser A and the web server is still opened, so 
>> another httpd child process answers the request.
> 
> 
> I thought one of the points being raised (can't find the mail/thread I'm
> referring to now) was that somehow confusion might ensue from a mix-up,
> on the Apache/PHP level, regarding the client identity, thus corrupting a
> transaction in progress. It seemed to make sense but now that we've
> discussed it, I can't see anymore how it might happen.
> 
>  . . . [ goes away to search mail archives ] . . .
> 
> Ah, here we go. A post from Rod Taylor on pgsql-hackers on Dec 27:
> 
> -- begin quote --
> The *real* problem with persistent connections is:
> 
> Script1:  BEGIN;
> Script1:  UPDATE table set row = 'things';
> Script2:  Insert into table (id) values ('bad data');
> Script1: COMMIT;
> 
> Since script2 managed to do a BAD insert in the middle of script1's
> transaction, the transaction in script1 fails.  Obvious solution?  Don't
> do
> connection sharing when a transaction is enabled.  The whole persistent
> connection thing is only valid for mysql as it's the only thing that
> doesn't
> really support transactions (and even thats partially changed).
> 
> They need to look for stuff going through (keywords like BEGIN) and
> 'lock'
> that connection to the single entity that opened it.
> 
> It's much easier to write your own.  I wrote a few functions like:
> 
> get_connection('DB PARMS');
> begin_transaction();
> 
> commit_transaction();
> close_connection();
> -- end quote --
> 
> [ . . . ]
> 
>> My question would be, and seeing Adams thoughts, wouldn't it be the best 
>> optimization configuration of php.ini to have only one persistent conection? 
>> Wouldn't there be one per-child? Any way, you can't have two connections to 
>> the same httpd child.
> 
> 
> Those where my thoughts too (or, rather, Adams thoughts ;)), and this is
> what I am trying at the moment.
> 
> Regards, Frank
> 
hi,
i ran across this transaction problem vs. persistent conn in pgsql some time ago.

I found two workaround methods:
- don't use persistent conn's :-) or;
- start every conn with the usual pg_pconnect and then query a rollback to the server:
$query="ROLLBACK work;"

(this will kill any supposed transaction in ABORT STATE that some child had left).

postgres don't support nested transactions (yet), but when it does maybe you should 
add multiple "ROLLBACK WORK;" queries :-)

Regards,
Nuno




-- 
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]

Re: [PHP] Persistent connections and transactions

[Frank Joerdens]

On Thu, Jan 25, 2001 at 05:10:54PM -0300, Martin A. Marques wrote:
[ . . . ]
> OK, lets see if we can understand what each other is saying (maybe I'm not 
> getting your point here).
> Lets say browser A connects to the apache server, to a page using php code. 
> Lets say the code is OK (no bugs). Apache opens a persistent connection to 
> the database and starts executing the queries. Now the connection between the 
> apache server and the web browser doesn't close until the queries are all 
> finished and the output is send back to the browser.
> Now, how about if browser B connects to the apache server just in the middle 
> of the execution of the queries that browser A asked for?
> Well, the connection between Browser A and the web server is still opened, so 
> another httpd child process answers the request.

I thought one of the points being raised (can't find the mail/thread I'm
referring to now) was that somehow confusion might ensue from a mix-up,
on the Apache/PHP level, regarding the client identity, thus corrupting a
transaction in progress. It seemed to make sense but now that we've
discussed it, I can't see anymore how it might happen.

 . . . [ goes away to search mail archives ] . . .

Ah, here we go. A post from Rod Taylor on pgsql-hackers on Dec 27:

-- begin quote --
The *real* problem with persistent connections is:

Script1:  BEGIN;
Script1:  UPDATE table set row = 'things';
Script2:  Insert into table (id) values ('bad data');
Script1: COMMIT;

Since script2 managed to do a BAD insert in the middle of script1's
transaction, the transaction in script1 fails.  Obvious solution?  Don't
do
connection sharing when a transaction is enabled.  The whole persistent
connection thing is only valid for mysql as it's the only thing that
doesn't
really support transactions (and even thats partially changed).

They need to look for stuff going through (keywords like BEGIN) and
'lock'
that connection to the single entity that opened it.

It's much easier to write your own.  I wrote a few functions like:

get_connection('DB PARMS');
begin_transaction();

commit_transaction();
close_connection();
-- end quote --

[ . . . ]
> My question would be, and seeing Adams thoughts, wouldn't it be the best 
> optimization configuration of php.ini to have only one persistent conection? 
> Wouldn't there be one per-child? Any way, you can't have two connections to 
> the same httpd child.

Those where my thoughts too (or, rather, Adams thoughts ;)), and this is
what I am trying at the moment.

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]

Re: [PHP] Persistent connections and transactions

[Martin A. Marques]

El Jue 25 Ene 2001 16:49, Frank Joerdens escribió:
> 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:
>
> 
>   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().
> 

Yes, I got this mail from Adam, but I think it was on the IMP mailing list or 
the Postgres-devel mailing list. Well, that doesn't matter to much. ;-)
Any way, it speaks very bad about the logic that PHP has of what is a 
persistent connection (I think I had the same problem with informix).

> > 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.

OK, lets see if we can understand what each other is saying (maybe I'm not 
getting your point here).
Lets say browser A connects to the apache server, to a page using php code. 
Lets say the code is OK (no bugs). Apache opens a persistent connection to 
the database and starts executing the queries. Now the connection between the 
apache server and the web browser doesn't close until the queries are all 
finished and the output is send back to the browser.
Now, how about if browser B connects to the apache server just in the middle 
of the execution of the queries that browser A asked for?
Well, the connection between Browser A and the web server is still opened, so 
another httpd child process answers the request. If a persistent connection 
is needed (as Adam said) this child will open a new one, because the other 
one is still in use.
So now you have two web connections with two backend connections.

My question would be, and seeing Adams thoughts, wouldn't it be the best 
optimization configuration of php.ini to have only one persistent conection? 
Wouldn't there be one per-child? Any way, you can't have two connections to 
the same httpd child.

Saludos... :-)

-- 
System Administration: It's a dirty job, 
but someone told I had to do it.
-
Martín Marqués  email:  [EMAIL PROTECTED]
Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-

-- 
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]

Re: [PHP] Persistent connections and transactions

[Frank Joerdens]

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:


  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().


[ . . . ]
> > 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]

Re: [PHP] Persistent connections and transactions

[Martin A. Marques]

El Jue 25 Ene 2001 14:34, Frank Joerdens escribió:
> On Thu, Jan 25, 2001 at 11:18:49AM -0300, Martin A. Marques wrote:
> [ . . . ]
>
> > No, and thats why in the postgres list we talked about persistent
> > connections not having much benefits. That is because the connection is
> > persistent to the httpd child that called it and not to all.
>
> Well, yes, but as long as the child lives, it'll be connected which
> means that every subsequent request to this child involving a database
> connection won't have to suffer the connection startup cost. If you have
> a rather inexpensive query, and a lot of web apps use simple,
> straightforward selects that are very inexpensive, then the connection
> startup overhead contributes more to the performance hit than the actual
> query.

Of course. But the persistent connection are not working as the manuals say 
they should work.

> [ . . . ]
>
> > Now be carefull. http connection open and close, they do not stay open,
> > so if you try to execute different SQL statments with different httpd
> > connections, your gonna have trouble (the sql server won't let you,
> > because there is another transaction been executed).
>
> 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.

Saludos... :-)

-- 
System Administration: It's a dirty job, 
but someone told I had to do it.
-
Martín Marqués  email:  [EMAIL PROTECTED]
Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/
Administrador de sistemas
-

-- 
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]

Re: [PHP] Persistent connections and transactions

[Frank Joerdens]

On Thu, Jan 25, 2001 at 11:18:49AM -0300, Martin A. Marques wrote:
[ . . . ]
> No, and thats why in the postgres list we talked about persistent connections 
> not having much benefits. That is because the connection is persistent to the 
> httpd child that called it and not to all.

Well, yes, but as long as the child lives, it'll be connected which
means that every subsequent request to this child involving a database
connection won't have to suffer the connection startup cost. If you have
a rather inexpensive query, and a lot of web apps use simple,
straightforward selects that are very inexpensive, then the connection
startup overhead contributes more to the performance hit than the actual
query.

[ . . . ]
> Now be carefull. http connection open and close, they do not stay open, so if 
> you try to execute different SQL statments with different httpd connections, 
> your gonna have trouble (the sql server won't let you, because there is 
> another transaction been executed).

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.

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]

Re: [PHP] Persistent connections and transactions

[Martin A. Marques]

El Jue 25 Ene 2001 10:21, Frank Joerdens escribió:
> On the PostgreSQL lists there has been some discussion recently as to
> the mechanism behind, benefits and drawbacks, of persistent connections.
> In particular a scenario similar to the following was brought up:
>
> Browser A connects to Apache child N, and calls a web page that calls a
> script which issues SQL commands that involve opening and committing a
> transaction:
>
> - begin work;
> - do some selects, inserts, deletes, updates . . .
>
> Now, the question is: Is it conceivable that in the meantime, whilst
> Browser A is waiting for the output from the script, that Browser B
> talks to same Apache child, uses the same persistent connection, and
> messes up the transaction that Browser A initiated in some unpredictable
> way?

No, and thats why in the postgres list we talked about persistent connections 
not having much benefits. That is because the connection is persistent to the 
httpd child that called it and not to all.

> - do more selects, inserts, deletes, updates . . .
> - commit work;

Any way, for the SQL statements you wrote here, Browser B cound never (and 
this is because postgres won't let it) mess with the transaccion browser A is 
doing.

> My guess would be that the Apache child wouldn't allow Browser B to talk
> to it whilst Browser A is waiting for output from the script and that
> that means that everything is fine and hunky-dory . . . I'm not sure
> though, and there is nagging trace of murkiness.

Now be carefull. http connection open and close, they do not stay open, so if 
you try to execute different SQL statments with different httpd connections, 
your gonna have trouble (the sql server won't let you, because there is 
another transaction been executed).

Saludos... :-)

-- 
System Administration: It's a dirty job, 
but someone told I had to do it.
-
Martín Marqués  email:  [EMAIL PROTECTED]
Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-

-- 
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]

[PHP] Persistent connections and transactions

[Frank Joerdens]

On the PostgreSQL lists there has been some discussion recently as to
the mechanism behind, benefits and drawbacks, of persistent connections.
In particular a scenario similar to the following was brought up:

Browser A connects to Apache child N, and calls a web page that calls a
script which issues SQL commands that involve opening and committing a
transaction:

- begin work;
- do some selects, inserts, deletes, updates . . .

Now, the question is: Is it conceivable that in the meantime, whilst
Browser A is waiting for the output from the script, that Browser B
talks to same Apache child, uses the same persistent connection, and
messes up the transaction that Browser A initiated in some unpredictable
way? 

- do more selects, inserts, deletes, updates . . .
- commit work;

My guess would be that the Apache child wouldn't allow Browser B to talk
to it whilst Browser A is waiting for output from the script and that
that means that everything is fine and hunky-dory . . . I'm not sure though,
and there is nagging trace of murkiness.

Cheers, 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]