Received: from hse-toronto-ppp119263.sympatico.ca (HSE-Toronto-ppp267981.sympatico.ca [64.230.57.62]) by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f0248eL26812 for ; Mon, 1 Jan 2001 23:08:40 -0500 (EST) (envelope-from rbt@zort.on.ca) Received: (qmail 3337 invoked by uid 0); 2 Jan 2001 04:08:31 -0000 Received: from unknown (HELO jester) (10.0.0.101) by hse-toronto-ppp267981.sympatico.ca with SMTP; 2 Jan 2001 04:08:31 -0000 Message-ID: <018e01c07471$a1db1570$6500000a@jester> From: "Rod Taylor" To: "Bruce Momjian" Cc: References: <200101020357.WAA06712@candle.pha.pa.us> Subject: Re: PHP and PostgreSQL Date: Mon, 1 Jan 2001 23:08:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Archive-Number: 200101/12 X-Sequence-Number: 2684 It was obviously designed with MySQL's "Nobody needs transactions for webwork" type of situation in mind. > This is interesting. I always wondered how the persistent connection > stuff handled this, and not I see that it doesn't. > > [ Charset ISO-8859-1 unsupported, converting... ] > > > The only problem we have run into (and I have heard of others having this > > > problem also) is with persistent connections. I have seen discussion on > > > persistent connection problems but I'm not sure the problem was ever > > > resolved. The problem we have seen is that when using persistent > > > connections the web server doesn't seen to reuse the connections or > > somthing > > > to that effect. The result being that we eventually use up our postgres > > > limit of 48 connections and nothing can connect to postgre anymore. It is > > > possible that this is a configuration problem that we haven't sufficiently > > > investigated, but I meniton it because I have heard other talk of this. > > > Anyone have more information? > > > > 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(); > > > > All of this is done in a class which has knowledge of all connections that a > > script is currently using. Beginning a transaction locks down the > > connection from use by any other handler, they're all bumped to another one. > > Problem? It requires atleast 1 connection per page, but since they're > > actually dropped at close it's not so bad. > > > > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 >