db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Shea" <s...@ps1.net>
Subject RE: OJB usability - part 5 of 5: caching
Date Wed, 15 Oct 2003 15:15:28 GMT
	Chris, did you submitted your concerns to the OJB team before writing these
unjustified comments? Just the fact that you're complaining about
scalability of OJB by testing against MySQL indicate to me that you have
very little understanding of general database usage.

	If you're building a medium to large application then MySQL is out of the
question, it's missing to many basic features.

	If you want to scale then your database is your caching engine, not OJB.
Caching in general is a mix of good and bad. In my project I had to turn
caching off for certain classes also if I really want to scale and go to
clustering or load balancing then caching is not welcome at all.

	I wrote an entire different configuration engine for OJB and found that I
could easily call the api to do whatever I wanted from it.

	Seems to me that you either didn't work hard enough or don't have a clue
how to write a persistence layer in java.

	Patrick Shea
	pshea@phs3.net

-----Original Message-----
From: Chris Giordano [mailto:giordano@more.net]
Sent: Wednesday, October 15, 2003 7:51 AM
To: ojb-dev@db.apache.org
Subject: OJB usability - part 5 of 5: caching


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.getObjectByIdent
ity()).

We found that using OJB within Tomcat was such a performance drain it
clearly
wasn't scalable by any measure.  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.

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.

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


Mime
View raw message