Re: [0.2] getting transactions to work
От | Marco Colombo |
---|---|
Тема | Re: [0.2] getting transactions to work |
Дата | |
Msg-id | 41135725.70304@esi.it обсуждение исходный текст |
Ответ на | Re: [0.2] getting transactions to work (reiner peterke <zedaardv@drizzle.com>) |
Ответы |
Re: [0.2] getting transactions to work
|
Список | pgsql-php |
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@ESI.it
В списке pgsql-php по дате отправления: