db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kalén <mka...@apache.org>
Subject Re: PreparedStatement caching
Date Mon, 25 Apr 2005 18:40:28 GMT
Armin Waibel wrote:
> Now it's totally different. The PB, ODMG API are only 35% slower than 
> plain JDBC. The statement cache boost performance.
> Is it reasonable to include a new configurable feature 
> "statementCaching=on/off" in 1.0.x and 1.x or should always the 
> jdbc-driver or connection-pool do such things?

Anything that can boost OJB performance and that is switched off by default
should only be a benefit, as far as I can tell.

But please leave this disable by default since memory requirements usually
rise quite rapidly if caching stuff that might hold on to ResultSet data etc
and since it might introduce extra overhead for the drivers that already do
caching of PreparedStatement automatically.

When you create your implementation, also consider dropping everything from
you cache that does not have any positional parameter at all since caching
  SELECT column FROM TABLE WHERE conditional_column = 1;
  SELECT column FROM TABLE WHERE conditional_column = 2;
  SELECT column FROM TABLE WHERE conditional_column = 3;
will fill up the cache quickly and stop it from making greater benefit for
proper reusable statements like:
  SELECT column FROM TABLE WHERE conditional_column = ?;
(Since I assume you have some LRU/round robin or similar algorithm with
  a fixed max size.)

Also, when you are working in this area: could you have a look at this class:

To me it looks really similar to StatementsForClassImpl, but never (?) had a
commented entry in OJB.properties for StatementsForClassClass setting and
is per Vadim's last patch outdated (not supporting ResultSet as out-param
from callable statements). Could we just remove this class?


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message