Afraid of LIE (LazyInitializationException)… Don’t Be.

Sharad Jain, Sunday, October 21, 2007 @ 4:29 pm

All the fuss around LIE reminds me of my days when I was scared of NPE (NullPointerException). No matter how hard I tried, I just couldn't write code that couldn't run into NPE. Slowly, I learnt that it is not a question about not running into NPE, it is about implicit awareness about the possibility of any reference being a null at any given place and time in code. Isn't LIE very similar to NPE in that way?

Folks are afraid of switching from Hibernate 2.0 to Hibernate 3.0 because their app starts throwing LIE everywhere as soon as they do. So, instead of trying to figure out the reason for this. They switch back to 2.0.

Follow these simple rules and we can avoid LIE in most places:

• Use OpenSessionInViewFilter (OSIV), it is your friend (as described here and here): Atleast in web applications, this ensures that you have a valid session in all layers - controller, service and finally view. One argument I came across recently against OSIV-filter is that it couples your application with Hibernate and makes it harder to replace persistence layer with some other persistence mechanism. An interesting thought! But does it really stick? Think about it. Any persistense framework will either not use lazy loading (like hibernate 2.0 did) or have some mechanism for loading object on demand ("lazy" that is).
• Avoid keeping reference to a hibernate managed entity outside of a hibernate session: If you need to keep an object around longer than a request (http-request or any other request), create a data-transfer-object out of your hibernate object. There are few common situations where this occurs most often. Currently Logged in user's information is retrieved from database when the user logs in and is kept in HttpSession. It is very easy to get into the habit of modifying this User object in HttpSession and trying to save it which will run you into Hibernate Merge issues. The easier (and Hibernate mechanism independent) solution is to create UserDTO and keep that in HttpSession. Another common situation is when you need to use caching to reduce database load. Again, why not use DTO(s) inside cache and not hibernate managed entities. It can be argued that this promotes struts action-form like anti-pattern ("bridge" anti-pattern?). However, I prefer keeping a known entity (fully initialized with a controlled hierarchy depth) around than a magical entity (hibernate object that may not have been fully initialized).

Just like NPE, once we ensure that an open connection to database (hibernate session) exists whenever we deal with a hibernate managed entity, we can avoid LIE.

Related posts:

1. Hibernate Gotcha: java.lang.IndexOutOfBoundsException: Remember that ordinal parameters are 1-based!
2. Using Hibernate with ZK
3. Grails: Delegating to GORM Persistence in Java
4. ADO.NET Entity Framework
5. .NET 3.5 Linq to Sql and IBatis.NET

Comments (0)

Technologies and Platforms

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment