Re: [ajug-members]: DB abstraction summary?

["Les A. Hazlewood" <les@hazlewood.com>]

Hibernate performs and scales extremely well for us in a high-volume, near
real-time distributed system, using a highly-normalized RDMBS.  We push it
pretty far.  In fact, because of transaction optimization, intelligent caching
and configuration options available to Hibernate that aren't available to
direct JDBC, I've found Hibernate to be as equally performant (and in most
cases even more performant) than writing hand-coded JDBC.

This isn't to say that JDO can't be equally as performant.  It is entirely
dependent upon the JDO implementation.

The biggest problem that I have with JDO is that OQL isn't nearly as flexible
and powerful when compared to Hibernate's query language in an RDBMS
environment (we don't use OODBMS's, in which case HQL is not even an option). 
This issue, coupled with the fact that there wasn't a decent/scalable
open-source JDO implementation to test for rapid prototyping is what allowed me
to choose Hibernate as the clear solution for our needs.  I've been extremely
happy.

JDO 2.0 is supposed to solve many of the inconveniences and inefficiencies of
OQL, but the JDO expert group has been particularly sluggish as of late in
working on the spec.  It may be a while until we see 2.0.  Gavin is still up in
the air when it comes to making Hibernate JDO compliant.  I know JDO 1.0
compliance is not even an option for Gavin, since he feels that JDO 1.0 as a
specification of functionality is rather immature and limited compared to
Hibernate's current capabilities, a statement with which I completely agree. 
JDO 2.0 may be an attainable goal for Hibernate in the future, but that won't
come about until after the 2.0 specification is finalized.  And as I've stated,
that may be a while.

I think what is more important than JDO or Hibernate per se is the architectural
design patterns used to access your EIS.  My company works in a contract-driven
environment, where JDO may be required by contractual specification (somewhat
unlikely, but possible nonetheless).  All of our data access is abstracted
using DAO (Data Access Object) interfaces, and the implementations of those
interfaces can be swapped out easily via deployment configuration.  We can use
a HibernateUserDAO implementation one day and a JDOUserDAO the next...it
requires no code changes to any of our application classes that use a
*UserDAO*.

Whatever your choice, if you ensure that your architecture supports this type of
swapping, you can switch between JDO implementations and Hibernate at will and
see what works best for you.  Your application will also be more resilient to
change and you'll find maintenence over time much more manageable.

Les


Quoting Angus Berry <angus.berry@elken.com>:

> I think we're on the same sheet of paper regarding 'scalability', I'll
> forward you the emails I got from OJB folks regarding JDO, so you can be
> sure.
>
> Regarding Hibernate & JDO, I found some ng postings on google or
> groups.google.com, from late 2003 by Christian, that were discouraging
> about JDO & Hibernate in the short term, but they were prior to JBoss's
> involvement, so the landscape may have changed. I can't really comment
> about Hibernate otherwise, as I haven't recently pushed it very far. May
> some else can illuminate about Hibernate & JDO.
>
> For me Patrick Linskey summed up a key benefit of JDO (you'd have to
> check the audio file for the exact quote), in that it allows you to
> 'defer decisions' until deployment, which is true even now with OJB-JDO.
> You could theoretically code right now against JDO on OJB and get to
> production time and pick another JDO compliant implementation to suit
> your needs. I know his product had some great features that are beyond
> my current requirements, but the ability simply swap out the persistence
> layer for new back end features like failover, would be music to most
> project stakeholder's ears.
>
> I'll shoot you those emails now.
>
> On Tue, 2004-05-04 at 18:20, John Wells wrote:
> > Angus Berry said:
> > > I hope I wasn't accidentally creating any FUD around OJB... the JDO
> > > reference implementation doesn't scale and also Licensing could be murky
> > > water since they graft on Sun's work.
> >
> > Angus,
> >
> > I'm still a bit hazy on what you mean.  Scalability means to me that you
> > can accomodate increased application load with additional resources...are
> > you saying that the JDO reference implementation doesn't perform well as
> > your application data size grows?
> >
> > How does Hibernate compare, out of curiosity?
> >
> > Thanks,
> > John
> >
> >
> > 0
>
>