[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