Re: caching query results
От | alex b. |
---|---|
Тема | Re: caching query results |
Дата | |
Msg-id | 3ECE348B.7040900@gmx.de обсуждение исходный текст |
Ответ на | Re: caching query results ("scott.marlowe" <scott.marlowe@ihs.com>) |
Ответы |
Re: caching query results
Re: caching query results |
Список | pgsql-general |
hello! yes, I have already found out, that a transaction is over with each CGI-connection and its disconnection... now, I'd be interested in that connection pooling... any ideas, where I'd have to start? TIA scott.marlowe wrote: > 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 по дате отправления: