Re: [0.2] getting transactions to work

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(at)postgresql(dot)org
[mailto:pgsql-php-owner(at)postgresql(dot)org]On Behalf Of Marco Colombo
Sent: Friday, August 06, 2004 3:02 AM
To: reiner peterke
Cc: pgsql-php(at)postgresql(dot)org
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(at)ESI(dot)it

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster