Re: caching query results

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: caching query results
Дата
Msg-id Pine.LNX.4.33.0305220841220.23585-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: caching query results  ("alex b." <mailinglists1@gmx.de>)
Ответы Re: caching query results  ("alex b." <mailinglists1@gmx.de>)
Список pgsql-general
On Wed, 21 May 2003, alex b. wrote:

> hello dear people without shaved necks!
>
> as many of you have already told me cursors are the way to go - now I know!
>
> there it is, kindly provided my BILL G.:
>
>    BEGIN;
>    DECLARE <cursorname> FOR <query>;
>    FETCH <number_of_rows> FROM <cursorname>;
>    MOVE {FORWARD|BACKWARD} <number_of_rows> IN <cursorname>;
>
>
> THANK YOU ALL VERY VIEL (much in german)!!!
>
> I will now have to implement session ID's into my CGI's...
>
> oh by the way... lets say a transaction has begun and was never
> commited.. what will happen to it?
>
> is there a automatic rollback after a certain time?
> or would there be ton's of open transactions?

Well, transactions can't stay open across a disconnect / reconnect, so
you'll have to use some kind of connection pooling to ensure they stay
open between invocations of your cgi scripts.

What environment are you developing in?  Java has pretty good connection
pooling, and so does PERL.  PHP, not so good, but you can work around it
if you understand the underlying, uber simple persistant connection
methodology.

There may be some open source connection pooling packages that can hold
the transactions open for your cgi scripts, but I've not played with
actual CGI in a few years now, so I have no clue how well any thing like
that would work.


В списке pgsql-general по дате отправления:

Предыдущее
От: Thomas Beutin
Дата:
Сообщение: Re: compiling mod_auth_pgsql
Следующее
От: "scott.marlowe"
Дата:
Сообщение: Re: VACUUM and transaction ID wraparound