Re: PreparedStatement
On 24.06.2010 16:51, Lew wrote:
Arne Vajh=F8j wrote:
Note that good database connection pools are able to reuse
real driver prepared statement even if the pool driver
prepared statement is not reused.
Robert Klemme<shortcut...@googlemail.com> wrote:
Good point! I have to say I'm wary to use those features as long as
You're wary to use which features? PreparedStatement? Database
connection pooling?
I meant to say I am wary to rely on a pool caching prepared statements
if either the environment of the JDBC application is undefined or may
change. All I was trying to say is that it should not be taken for
granted that the overhead of Connection.prepareStatement() is always low =
just because there are situations (the mentioned pools which cache PS)
where this is the case.
there is no guarantee that the environment of an application is
stable. If it has to run with a pool with and without PS caching you
need to to the caching yourself. Otherwise you might see dramatic
performance differences. If you know the app is only ever going to be=
used in an environment relying on this feature is of course perfectly
OK.
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.
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.
Unless you meant some other features, in which case I don't understand
your comment.
I was probably too unclear. Sorry for that.
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/