by the way, jsp supports connection pooling quite well.
Do you have a specific development environment you have to work in?
On Fri, 23 May 2003, alex b. wrote:
> 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.
> >
> >
>
>
