[DB-SIG] query - prepared statment
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
> > 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
More information about the DB-SIG