Comments on: Hibernate Pitfalls part 2

By: Andre Piwoni

Andre Piwoni — Fri, 23 Oct 2009 00:34:19 +0000

In response to jens statement that
“OK setting FLUSHMODE to never is easy but you first have to figure this out and you then introduce some strange “Persistance Layer” dependant Logic into your code”

What do you mean by strange persistance layer? You access data via simple persistence layer (think of something like Generic DAO) which encapsulates this behavior? How complex this is:

public void delete( T argObject )
{
Session session = getSession();
session.delete( argObject );
session.flush();
}

When you are done code upstream does commit or rollback.
Is there anything that you see here that requires upstream code to have some persistence layer dependent logic?

By: inca

inca — Sat, 17 Oct 2009 11:38:30 +0000

“Automatic dirty checking” is a design pattern, that has it’s own synopsis and therefore fits only certain circumstances. Apparently, it does not fit the Open Session In View pattern: collecting values into an attached entity object, then validating this object and then deciding, whether persist it or not. While the session is alive all the way, you’ll get updates before you will be able to validate (even if you will eventually decide not to do so).
Now a word about workarounds. The worst thing the developer may do is to introduce his own workarounds to avoid some undesirable features.

By: jens

jens — Sun, 13 Sep 2009 16:03:58 +0000

Hello,

I also think Brians Post is very helpfull. Thank you very much Brian, please keep up the good work.

Hibernate tries to “solve” some of the problems of the SQL/Relationalworld but on the otherhand therefore imposes problems on another level. Hibernate tries sometimes to be too smart. In regard to the article the FLUSHMODE = AUTO I consider not necessarly as a Feature. I had serious Problems for example if you do a series of validations and one fails then the object is in an indeterministic state. But Hibernate happly will update the database. You than have to introduce logic to prevent this. OK setting FLUSHMODE to never is easy but you first have to figure this out and you then introduce some strange “Persistance Layer” dependant Logic into your code. So I think the post Hibernate Pitfalls 1 an 2 are very helpfull!

By: Kurt Harriger

Kurt Harriger — Sat, 22 Aug 2009 04:46:24 +0000

I agree… just blogged about this myself.

http://kurtharriger.wordpress.com/2009/08/21/how-nhibernates-dirty-checking-violates-encapsulation-boundries/

By: Carlos

Carlos — Thu, 13 Aug 2009 20:11:58 +0000

Again this post is simple ignorance of the principles behind the development of Hibernate.

I agree with Andre Piwoni, all of these pitfalls can be fixed by setting AutoFlushMode = Never

By: inca

inca — Sun, 12 Jul 2009 13:09:20 +0000

No, Mark, it is not. I personally will never fall back to plain JDBC even in the most trivial cases. And still these implicit updates are lame stuff for sure. I would at least consider it being optional feature (disabled by default).
As for the Christian’s comment — the worst workaround for such an offense. Are POJOs recovered from persistence context supposed to participate in some business logic? And what if, depending on that logic, you eventually decide to persist them? If you only have a handfull of queries, then it is probably OK (very ugly though and, yepp, I didn’ manage to find an equivalent in Criteria API, which is essentially the ‘O’ of ORM), but as soon as you deal with tons of queries within a transaction you just have to call readOnly on a unit-of-work, rendering it unable to do further persistence stuff.
Actually I have never saw a beautiful solution for that ‘feature’ — just ugly workarounds.

By: Mark

Mark — Thu, 25 Jun 2009 16:07:37 +0000

I totally agree with Brian and StickyBandit. We are using Hibernate for our project and writing HQLs most times. I really don’t see any point using Hibernate. In most cases, I believe, the pure JDBC is still the best way to go.

By: StickyBandit

StickyBandit — Fri, 12 Jun 2009 20:34:35 +0000

Remember the Atari game ‘Pitfall’? That’s what it’s like using hibernate. You have to jump over one pit and then onto the next pit, jump, jump, jump. I am doing all this so that I don’t have write some SQL? Hardly seems worth it to me. Especially when I still end up writing SQL wrapped in HSQL for all the complex stuff anyway. Huh? Am I the only one who thinks this is the worst idea that ever got popular?

By: Pete

Pete — Thu, 06 Nov 2008 11:16:27 +0000

Brian Pontarelli’s post a year and a half ago just helped massively. We had Hibernate automatically saving objects to the database without being asked - calling session.clear() was the solution. Brian’s post was clearer than all the hibernate documentation!

By: Dan

Dan — Fri, 26 Sep 2008 16:27:58 +0000

We ran into this same issue recently. We were surprised to have objects persisted when we never called save on them. Pretty lame “feature” if you ask me. Calling evict or session.clear is not a good solution for this issue.