actually, mod_perl is "supposed" to allow a web app to be written such that the db connections are resident in memory, and therefore, available to multiple pages across the web app for a given session.... i haven't tried/tested this, but i've heard that it is supposed to be possible. i've had an email exchange with one of the mysql developers who states that this kind of functionality wil be built into the mysql app and should be available within the next 3-4 months... regards, -----Original Message----- From: pgsql-php-owner@xxxxxxxxxxxxxx [mailto:pgsql-php-owner@xxxxxxxxxxxxxx]On Behalf Of Marco Colombo Sent: Friday, August 06, 2004 3:02 AM To: reiner peterke Cc: pgsql-php@xxxxxxxxxxxxxx Subject: Re: [0.2] [PHP] getting transactions to work reiner peterke wrote: > well i've read about this thing called persistent connection, > i think it is supposed to exist in mysql also. the idea sound like what > i want. i've tried it but i didn't get any different results. but then > i'm not convinced i did it right either. You have to face the fact that HTTP is _stateless_. Any common HTTP server will obey to that, thus destroying any resource related to the request it just served, _or_ making it appear as if it was destroyed. You really need to think hard of the implications here. Persistent connections are no exception: they are just a way to boost perfermance, but there should be no visible difference at application level. That is, you should be able to change pg_connect()'s with pg_pconnect()'s (and vice versa) without changing anything else in your PHP scripts. Persistent connections add _no_ extra functionality to your PHP application. Transactions exist at SQL session level. A "session" is inherently statefull, and will be destroyed (or made appear as destroyed) at the end for each HTTP request, because it _has_ to appear stateless. The request for the 'next' page may be served by a different process, or a even a different host, so no state can be shared. There's simply no way you can control this. Sessions/cookies alone won't let you use transactions, they'll just emulate them. You can delay the transaction till the final page, but it's just not the same. Of course, you can write your own HTTP server (there are simple-to-use Perl or Python modules to do that) that deliberately fails to adhere to the HTTP model, and keeps some state. If you control all the environment, that may even work. One possible solution is to write proxy application (a server), which talks on one side to the SQL db and on the other to the PHP frontend. .TM. -- ____/ ____/ / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _____/ _____/ _/ Colombo@xxxxxx ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
