db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Giordano <giord...@more.net>
Subject Re: OJB usability - part 5 of 5: caching
Date Mon, 20 Oct 2003 16:06:22 GMT
Hi Thomas,

Thomas Mahler wrote:

> 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. 


Thank you and Armin for clarifying the operation of cache.  In the 
future, we'll be certain to bring up an issue such as this on the list 
before
arriving at a false conclusion.

Chris.

>
>
>>
>> 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 
> sucsess-stories.
> 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.
>
> Thomas
>
>
>> 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
>


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


Mime
View raw message