Spring, Hibernate and leaky abstractions

By Confusion on Friday 20 February 2009 22:33 - Comments (3)
Categories: Java, Software engineering, Views: 6.423

The advantage of using frameworks/libraries like Spring and Hibernate is supposed to be that they take care of the nasty details and that you only need to think about what you wish to do on a much higher level. However, abstractions are always leaky and when you run into a problem, you still need to understand about the nitty-gritty details.

This week, I ran into the following problem: my Spring/Hibernate based application locked up. It was reproducible and seemed to depend on the number of queries that had taken place. So I started Tomcat with

told Eclipse to connect to that socket (debug remote application) and suspended operation after the application frooze. The result was clear: no more connections in the connection pool and an infinite wait until one would be available.

Now this application is reasonably old and has worked succesfully for quite a while. Everything seemed to be in order, until, after looking at the Javadoc of the HibernateDaoSupport class for the umpteenth time, it suddenly hit me: the latest DAO used getSession() instead of getSessionFactory().getCurrentSession() to obtain a session. While the first could very well be a shorthand for the latter, it most certainly isn't. I noticed the difference when I reviewed the differences when updating from Subversion and read the appropriate Javadoc, but I wasn't paying enough attention to realise that the difference between these ways of obtaining a Hibernate session was a nitty-gritty detail that was very important.

Volgende: Why functional programming doesn't catch on 02-'09 Why functional programming doesn't catch on
Volgende: Using grails on an existing database 02-'09 Using grails on an existing database


By Tweakers user Apache, Saturday 21 February 2009 13:33

It's funny, yesterday a collegue was working on an application also using the HibernateDaoSupport and basically doing the same thing, sometimes using getSession, and sometimes the getSessionFactory().getcurrentSession().

It can also lead to: Hibernate Exception: Illegal attempt to associate a collection with two open sessions

All in all I think the HibernateDaoSupport is an unnessary layer of abstraction anyway and puts a hard dependency on spring. These days I prefer having just pojo's and injection a jpa entityManager ... although I also annotate it as @Repository ... kinda defeats the point of removing hard spring dependencies :D

By Tweakers user Confusion, Saturday 21 February 2009 14:47

Since Spring 2.0 you needn't use HibernateDaoSupport anymore, if you use the LocalSessionFactoryBean from the hibernate3 package. However IIABDFI :).

By Andew Ingram, Sunday 22 February 2009 19:39

I find that whilst Spring/Hibernate is very powerful, it introduces too many ways of things going wrong in an area outside of my expertise.

When our code by all accounts is not causing the problem, but rather our interaction with hibernate sessions and connection pooling, it makes it extremely difficult to debug without doing profiling on our production environment. I'm not very good at profiling Java apps so it introduces a new burden of expertise.

When I choose an ORM, all I want it to do is simplify the creation of SQL queries - If it does anything more it's making my life more difficult. If I have a performance problem I'll introduce a caching layer of my choosing. Every library should just solve one problem well. Between them, Spring and Hibernate seem to be trying to solve the whole Java platform.

Comments are closed