[DB-SIG] query - prepared statment

Jeff Lewis jlburly at yahoo.com
Sun Feb 12 00:30:42 CET 2006


--- Carsten Haese <carsten at uniqsys.com> wrote:
> On Sat, 11 Feb 2006 09:41:41 -0800 (PST), David
> Rushby wrote
> > --- Carsten Haese <carsten at uniqsys.com> wrote:
> > > I'm -1 on introducing a whole new class to
> encapsulate these deeper
> > > diagnostics.
> > > [...]
> > > If the programmer needs more than one prepared
> statement, nothing is
> > > stopping them from creating more than one
> cursor.
> > 
> > But this is akin to limiting Connections to having
> one Cursor open 
> > at a time, and saying, "if the programmer needs
> more than one cursor,
> >  nothing is preventing them from creating more
> than one connection."
> 
> That's a weak analogy. A connection implies a
> transaction, ...

A connection only implies a transaction when
autocommit is either set to true or when a
non-autocommit connection is opened, used,
committed/rolled back, and finally closed.  But what
about the case where a connection is cached, as in a
connection pool?  Pooled connections are used for
multiple transactions over time.  In the java world,
PreparedStatements are often pooled as well.  As such,
David's analogy seems valid to me.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


More information about the DB-SIG mailing list