Skip site navigation (1) Skip section navigation (2)

Re: Number of connections

From: Ernest E Vogelsinger <ernest(at)vogelsinger(dot)at>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: Raphael Bauduin <raphael(dot)bauduin(at)be(dot)easynet(dot)net>,David Busby <busby(at)pnts(dot)com>, <pgsql-php(at)postgresql(dot)org>
Subject: Re: Number of connections
Date: 2003-05-23 17:05:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-php
At 17:45 23.05.2003, scott.marlowe said:
>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 

I've read in another thread (either here, or in php-general) that PHP
clears out any transactions that might be open when you pg_connect() or
ph_pconnect(), by issuing "begin;rollback;".

If this is the case this would mean you simply CANNOT have transactions
open across multiple requests.

Which is a good thing IMHO. Just think of the mess that would be created if
client A opens a transaction, client B (using the same child process,
pg_pconnect()ing to the same database) runs a totally different set of
instructions and commits the transaction. A's "transaction" would be
partially committed by B...

Transactions are designed to be atomic operations, and I strongly believe
they should be treated exactly this way - begin, do your stuff, commit or
rollback. In one request. Anyway, pending transactions may lock rows or
tables, and may keep other parts of an application from running at all.

Just my 2c worth...

   >O     Ernest E. Vogelsinger
   (\)    ICQ #13394035

In response to

pgsql-php by date

Next:From: Lonnie VanZandtDate: 2003-05-23 17:26:08
Subject: Re: faster output from php and postgres
Previous:From: Frank BaxDate: 2003-05-23 16:49:37
Subject: Re: faster output from php and postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group