cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Baldwin <>
Subject Re: Cayenne vs Hibernate Comparison
Date Mon, 06 Sep 2010 20:31:58 GMT

Dude, you really have to start a cogent advertising campaign to promote Cayenne!  These differences
you point out (along with what I understand to be a deficiency in faulting behavior over the
lifetime of a data object), are not insignificant.  (I do believe that they are not widely
understood however.)

I was literally asked by a young project lead (in an aggressive tone) "why would you ever
use anything other than Hibernate".   This leads me to believe that they have not done their
homework.  I think that they could benefit from just the analysis share in today's emails.

I personally think that Cayenne takes the best concepts from NeXT-EOF, and Java and have evolved
them into a mature Enterprise-ready ORM (something I cannot say about the current version
of Hibernate).

While it would be great to have a book, and great to have an Entity Diagram integrator, I
think a simple "Why Use Cayenne" white-paper or web-page that succinctly illustrates these
differences would accomplish a lot.  Developers have come to rely upon and *expect* intelligent
garbage collection from Java (an arguably non-lanaguage related feature), why not be proactive
about asserting core Cayenne features as core ORM features in the larger community?


On Sep 6, 2010, at 3:57 PM, Michael Gentry wrote:

> The Hibernate Session is tied to a database connection.  A Cayenne
> DataContext requests a connection from the DB connection pool when you
> commitChanges() or performQuery() and then releases it when done.
> Hibernate therefore has issues in a web application where you don't
> know how many request/response trips will be made from the browser to
> the application -- you can't really leave the database connection open
> indefinitely.  Cayenne's DataContext transparently uses DB connections
> as needed and is more natural in this regard.  Hibernate's proxied
> objects are also tied to their Session.  This creates problems
> (faulting objects, updating and saving, etc) when the Session from one
> request/response was closed and then you try to use the objects in
> another request/response -- you have to re-attach objects to a
> Session.  Cumbersome.  Again, Cayenne does not have these problems.
> This issue was so bad in Hibernate that the Spring community created
> the Open Session In View filter and it still doesn't really solve the
> problems, but it does make it a little better.
> mrg
> On Mon, Sep 6, 2010 at 3:24 PM, Joe Baldwin <> wrote:
>> Robert,
>>> And basically, that's it in a nutshell.  The thread is discussing fetching a
lazy relationship after the session has closed.  If that were the /only/ "fringe case" of
lazy relationship navigation in hibernate, it would probably be tolerable.  But it turns out,
it's /not/ the only fringe case.  I constantly encounter what I would call "rough edges" around
Hibernate's lazy fetching.
>> It took a bit to find a simple quote from the thread, but I think this is it:
>> "The problem is in Hibernate's lazy loading: you can't load non-initialized objects
after session is disconnected/closed."
>> I am still a bit confused by the jargon, because I thought "hibernate session" was
analogous to "DataContext".  However, in this thread you referenced, it sounds like they are
using it as if it were analogous to a "transaction" or maybe even a transient "database connection".
>> Also, if I understand Gavin, (and as you point out) it sounds as if he does not embrace
"faulting behavior" (aka lazy fetching) as part of the core responsibilities of an ORM.
>> If I understand these comments, then I would have to disagree with their core ORM
design pattern, because it is my opinion that intelligent-faulting behavior is one of the
most important functions of an ORM.  NeXT/Apple EOF (one of the first ORM implementations)
included transparent faulting (very similar to Cayenne in behavior) well before Hibernate
was even started.
>> Again, if I understand the comments, the Hibernate faulting design sounds like a
very primitive and naive implementation.
>> Am I misunderstanding this (or being too harsh)?
>> Thanks,
>> Joe

View raw message