db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mahler Thomas <thomas.mah...@itellium.com>
Subject AW: Goals of the Jakarta-OJB project
Date Tue, 28 Jan 2003 08:43:52 GMT
Hi Chris,

> Hello all,
> I've been wondering for a while what the current goals of the 
> OJB project
> are.  Following the ojb-dev list has given me the impression that
> development is occurring in several areas, but I can't really see an
> overall direction.  Is there one overriding goal at the 
> moment?  Are there
> several?  

1. bring out a rock-solid 1.0 version in Q1 / 2003
2. start on building an OTM based ODMG refactoring and on an OTM based JDO

> And what is the primary argument for using OJB over, say,
> Hibernate?

A look at http://www.c2.com/cgi/wiki?ObjectRelationalToolComparison shows
that OJB and other O/R tools share a comparable feature set.
This is quite normal, as all these tools are addressing the sample problem

So mere features may not be an argument

Some months ago there were rumours that Hibernate performance was by far
better than OJB performance.
The Hibernate team had published a statement on their site stating that
their solution was much faster "than other well known opensource o/r tools".
As Jakarta OJB is a well known tool, people thought they were talking about
We gave it a try, we reimplemented the OJB performance suite against
Hibernate and found that both tool performed quite similar (OJB beeing 5-10
% faster).
We approached the Hibernate team to collaborate on a common performance
testsuite to allow users to decide on facts and not on propaganda.
Unfortunately they had no interest.

So mere performance may not be an argument.

Here are some things special for OJB:
- it's licenced under ASF licence and *not* under (L)GPL
- It provides multiple persistence APIs (PersistenceBroker, ODMG, JDO)
- It was designed to serve as a foundation for your own extensions and
derived performance mechanisms.
- It has a Modular component architecture that allows to plugin user defined
- The design is so flexible that it is easy to use OJB as a generic object
data integration facility and not as a mere O/R mapper (users have build
LDAP access etc.)

> I know that OJB has ODMG support, and wants to provide JDO 
> support, and
We already provide a full JDO 1.0 compliant solution!

> being standards compliant is always nice.  
> Is standards-compliance a
> primary goal of OJB?  

Yes, ODMG and JDO compliance have been goals since the project launch!

> And if so, does it trump performance

> and
> flexibility?  

> I often see developers questioning whether a (supposedly
> beneficial) change can be made to the PersistenceBroker 
> without breaking
> ODMG compliance.  

PB changes typically do not affect the ODMG level. Only in certain cases
ODMG semantics is affected.
The most tricky parts are transactional isolation and cache management.
Of course we have to take care to implement these things correctly. But
there is no tradeoff between ODMG compliance and Performance of the kernel.
Such a tradeoff would be a clear indicator of a poor design!

> Presumably the same questions will 
> eventually arise with
> JDO.  

The layering in OJB is quite clean. I wrote the JDO RI plugin within one day
without any changes to the PB kernel.

> Is the OJB developer community focused more on 
> providing a flexible,
> fast persistence layer,

> or on providing a standards-compliant 
> persistence
> layer?

performance and flebility are not concurring with standards compliance!
In fact it's the flexibility of the PB kernel that allows to build high
level transaction-managers on top of it.

> I'm not saying that either of those goals is better; it would just be
> helpful to know which is the goal.  To say that they are both 
> goals is an
> oversimplification though: when a conflict arises betweens 
> flexibility,
> performance, and standards, which wins?

As mentioned above, with OJB there is no conflict between these goals.
We are always trying to improve performance, both of the kernel and of the
high level APIs.
I just checked in a few ODMG performance patches last weekend.

> Thanks in advance for any responses.  I hope this generates 
> some useful
> discussion on the direction of OJB.

I hope so!

> Regards,
> Chris Greenlee
> cgreenlee@demandsolutions.com
> --
> To unsubscribe, e-mail:   
> <mailto:ojb-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:ojb-dev-help@jakarta.apache.org>

View raw message