cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Durchholz, Joachim" <>
Subject RE: lazy loading (slightly OT but still pretty important)
Date Fri, 30 Mar 2012 12:56:53 GMT
I agree the difference is the approach.

Hibernate strictly controls the staleness of objects. If a Session closes, the objects become
detached and potentially stale, and there's no way to make the current again (except by transferring
their contents to objects of a new Session). Hibernate goes to great lengths to protect that
The downside is that Hibernate cannot deliver on its promise of "work with entities as if
they were normal Pojos" - you need to safeguard against LazyInitializationExceptions, either
by making sure that everything ever needed is loaded up front (making it really hard to modularize
the code), or by restructuring the code so that any update process is wrapped in application-side
restartable Action objects, which is a heavy constraint on Java applications (unless they
are running inside a web service, where every request is, by nature, already an application-side
restartable Action object).

Cayenne doesn't care about staleness. It's the application's task to ensure that Pojo networks
are updated to the current DB state at the beginning of an application-side transaction. If
data isn't available yet, just load it - and accept the risk that the application may now
be working with partly stale, partly current data.

If you don't need non-staleness guarantees, Cayenne's way is far easier to work with.
If you do need non-staleness guarantees, this has massive consequences for application design
(i.e. things are getting ugly). Hibernate, IMHO, just exposes this ugliness and enforces it
on the application.

Now that's the conceptual difference. Hibernate also drops the ball on mitigation: you essentially
can't recover from a LazyInitializationException (or any other exception), the only thing
guaranteed to work is to delete all data and restart the DB transaction. (Again, this is a
question of how deeply entrenched your application is in strict transaction control; interactively
editing data in the DB definitely does not need that. The irony is that non-interactive code
usually does bulk updates, for which an ORM is usually not a good match anyway. I find Hibernate's
philosophy valid but suspect that it is suitable only for a rather small ecological niche.
It just happens to work reasonably well for web services, which is probably why it gained
so much traction.)

View raw message