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.
>
>
