db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: OJB usability - part 5 of 5: caching
Date Fri, 17 Oct 2003 17:22:01 GMT
Hi Chris,

Chris Giordano wrote:
> OJB developers:
> The following feedback intends to provide constructive comments to the
> OJB developers to improve the project as a whole.  The experiences and
> observations are meant to stimulate development of world class software.
> An open source dB persistence layer solution is needed and OJB may be
> positioned to provide this in the future.
> Our intention to use OJB was, in part, driven by the performance gain we
> could potentially achieve as queried Objects became accessible via the 
> cache.
> Then we did some performance testing.
> With MySQL as a backend datastore, we configured the JDBC driver to log SQL
> and found OJB's use of a cache is extremely limited.  In fact, the only 
> type of
> query that will actually look up an object in the cache is a query by 
> object
> identity 
> (Reference:org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByIdentity()). 

That's only partially true. All criteria or SQL based queries are always 
executed against the database. That's true.

But if a row of a resultset returned by such a query corresponds to an 
already cached instance, the instance is loaded from the cache and not 
materialized from the resultset.

So even sql or criteria based statements benefit from the cache. This 
can be easily verified by executing our performance testsuite.

To avoid the usage of database access for SQL and criteria based queries 
completely would require to build a SQL query engine on top of the cache.
I don't know any O/R tool that works this way.

> We found that using OJB within Tomcat was such a performance drain it 
> clearly
> wasn't scalable by any measure. 

This one makes me really laugh. There are lots of Tomcat / OJB 
We also provide some guidelines how to build highly scalable solution 
with OJB: http://db.apache.org/ojb/howto-work-with-clustering.html.
This howto explicitely mentions steps to achieve scalability by using 
special cache implementations.

> This was the single most determining 
> reason why
> we've backed out of using OJB entirely.  The use of the cache is going 
> to be
> critical if OJB is going to prove itself scalable for high volume 
> production
> use.  In fact, we're simply at a loss as to why anyone would logically 
> choose
> OJB for their next development effort due to this alone.

Mhh. I can't agree here. There are more reasons to use an O/R layer than 
just having a data cache.
We are using OJB even in situations where we know that handcoded SQL 
would be faster. We do so because the whole software modeling and 
implementation process gains quality by using an O/R persistence API.

> The OJB documentation is extremely deficient in describing the use of the
> cache.  It implies a much broader implementation and is very 
> misleading.  The
> recommendation here is for clear and thorough documentation - complete with
> limitations of usage, performance benchmarks, expectations etc.

Documentation can always be improved. Sure. But did you ever had a look 
at the documenation of of a commercial O/R tool?
For instance I never found any documentation about the TopLink caching 
mechanism that comes close to your expectations.


> Chris Giordano
> giordano@more.net
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org

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

View raw message