Re: PreparedStatement
Lew wrote:
If the environment is not stable, then performance variations are
normal and expected, and optimization is premature. This does not
militate against using PreparedStatement nor against connection
pools. It's beneficial to use both, and should be required to use the
former.
Robert Klemme wrote:
One definitively should use PS - just not mindlessly recreating a PS for
the same SQL via the Connection. That decision should be taken
consciously and if it is not known what the source of the Connection
does then IMHO it's better to keep PS around for the time that they are
repeatedly used with the same Connection.
I see your point and agree wholeheartedly.
I go a step further and suggest that one keep the PreparedStatement
around for use within the same use of a Connection regardless of the
promise you think the connection pool makes. From a logical
standpoint, an application acquires a new Connection each time; that
the Connection may be pooled and may be the same as one from an
earlier use is hidden from the application. Ergo, whether the
PreparedStatement obtained from the Connection is reused from an
earlier invocation is also hidden. Ergo, it is foolish to rely on
putative promises that depend on such reuse.
The point of connection pools is to let an application pretend that
it's getting a new Connection (and thus a virgin PreparedStatement)
each time even though under the hood the pooler is reusing them. You
can't simultaneously pretend that the Connection is new and rely on it
being reused.
--
Lew