PreparedStatement
in [Java Programming]
|
Prev: Newbie Q. Accessing a variable in one method from another.
Next: Is there a 'Filter' or 'Predicate' interface anywhere in the JDK?
From: Robert Klemme on 24 Jun 2010 08:40 On 24 Jun., 02:36, Arne Vajhøj <a...(a)vajhoej.dk> wrote: > On 23-06-2010 12:24, Robert Klemme wrote: > > > > > On 23.06.2010 12:33, Lew wrote: > >> gk wrote: > >>> Please see this .. > > >>>http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html > > >>> PreparedStatement : An object that represents a precompiled SQL > >>> statement. > > >>> "precompiled SQL statement" ... who compiled this ? > > >> There are a couple of layers of compilation, one at the JDBC layer > >> (potentially) and the other at the DBMS server. > > >> Precompilation is not the only benefit of prepared statements. > > >>> Is it working like this way ...when I first execute the code below > >>> DBMS compiles when it encounter for the first time and then next time > >>> DBMS does not compile . So, We call it precompiled. > > >> Roughly speaking, yes, although the full truth is somewhat more > >> complicated. > > > It is important to mention that for PS to work efficiently the statement > > must be kept in user code. Invoking prepareStatement() with the same > > string argument twice makes no guarantees about saving compilation in > > the DB. To make the code efficient user must prepare the statement and > > keep it around for recurring use. > > > That is, if you want to benefit from compilation savings - if it is only > > for avoidance of SQL injection / proper conversion of arguments and > > performance does not matter you can recreate PS over and over again- > > Note that good database connection pools are able to reuse > real driver prepared statement even if the pool driver > prepared statement is not reused. Good point! I have to say I'm wary to use those features as long as 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. Kind regards robert
From: Lew on 24 Jun 2010 10:51 Arne Vajhøj 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...(a)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? > 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. Unless you meant some other features, in which case I don't understand your comment. -- Lew
From: Robert Klemme on 24 Jun 2010 13:04 On 24.06.2010 16:51, Lew wrote: > Arne Vajhøj 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...(a)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/
From: Lew on 24 Jun 2010 13:56 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
From: Robert Klemme on 24 Jun 2010 14:38
On 24.06.2010 19:56, Lew wrote: > 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. That's a great way to express it - much better than my wariness. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ |