Re: Which one is better 1 connection lots of open cursors - more connections less open cursors

Plus, until JDBC 3, statements prepared on one connection could not be used with another connection. So it was simpler to prepare all statements on all connections, without worrying about which connection has which statements prepared on it.

  This functionality is now part of JDBC 3, though.

"Jim Kennedy" <kennedy-down_with_spammers_at_attbi.com> wrote in message news:<975za.695940$Zo.149622_at_sccrnsc03>...
> All cursors on one connection. If you start putting cursors on different
> connections you have the time of starting a new connection. Also with
> multiple connections you run into the problem of how to handle the different
> transactions that each connection is on. One connection might not see an
> update another one did, whereas they currently do since they are on one
> connection.
> Jim
>
> --
> Replace part of the email address: kennedy-down_with_spammers_at_attbi.com
> with family. Remove the negative part, keep the minus sign. You can figure
> it out.
> "Marc Eggenberger" <marc.eggenberger_at_itc.alstom.com> wrote in message
> news:MPG.1936a050d42464598969d_at_H02374...
> > Hi there.
> >
> > I've been asked this question.
> >
> > A java programmer told me that the application at his company is using
> > quite a few open cursors.
> > At the moment about 300 per "Special-User".
> > The normal User does not have that much. Dont know excatly, thats just
> > what he told me.
> > Now he asked which one would be faster. One connection with all the open
> > cursors or multiple connections (like 10) and then having the cursors
> > distributed over those connections.
> >
> > I would have said that the overhead of having multiple connections would
> > be greater and I would use the first approach. But I'm not sure. What
> > would you say?
> >
> > The app runs under Oracle 9R2 under Windows and Unix.
> >
> > Is there a signifikant difference? Or cant it be said because the
> > application is not know?
> >
> > Thanks for any comments
> >
> > --
> > mfg
> > Marc Eggenberger
Received on Fri May 23 2003 - 14:59:15 CDT