Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <426D399C.2000706@apache.org>
Date: Mon, 25 Apr 2005 20:40:28 +0200
From: =?ISO-8859-1?Q?Martin_Kal=E9n?= <mkalen@apache.org>
Organization: ASF
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: PreparedStatement caching
References: <426A821B.3040005@apache.org>
In-Reply-To: <426A821B.3040005@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
eg:
  SELECT column FROM TABLE WHERE conditional_column = 1;
  SELECT column FROM TABLE WHERE conditional_column = 2;
  SELECT column FROM TABLE WHERE conditional_column = 3;
  ...etc
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:
  org.apache.ojb.broker.accesslayer.SQLCachingStatementsForClass

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?

Regards,
  Martin

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