A Java geek

With such a controversial title, I’m bound to be the target of heated comments. Although provocative, such is not my goal, however, I just want to initiate an educated debate between people that are interested into thinking about the problem.

The origin of this post was a simple discussion between developers of different level of experience on Hibernate. The talk was about eager-, lazy-loading and the infamous LazyInitializationException. Since I imagine not everyone has the problem in his mind right now, let me resume it at first.

Most of the times, your entities have relations to one another: a course has students, an invoice has a customer, etc. These relations could take you really far (a student follow courses, which are taught by teachers, who in turn have other courses), and since most of the time, you don’t need the whole objects cluster, Hibernate let you define relations as either eager or lazy. Eager relations do get the association, while lazy relations are replaced by Hibernate by a proxy. These proxies do nothing until activated by calling the getter for the association. At this time, the proxy queries the database through its encapsulated Hibernate session.

If the latter is already closed, you’ll get the LayInitializationException, since Hibernate tries to query the DB without connection. However, there are 3 solutions to the exception.

The simplest is, of course to tag the relation as eager. Hibernate will never use a proxy, and thus, you’ll never have this exception (from this relation at least). This is not a solution per se, since if you do this with all relations, Hibernate will load all associations, and you’ll end up with a mighty big objects cluster. This defeats Hibernate lazy strategy as well as clutter the JVM’s memory with unused objects. Associations that are used throughout the application are a good candidate for eager tagging, but it’s the exception, not the norm.

Another solution for this is the OpenSessionInView “pattern”. Before going into explaining it, let me layout the whole thing.Good web applications are layered, meaning the persistence layer (the one nearer to the database) is responsible for interacting with the DB. Most DAO will open the Hibernate session at the beginning of the method (or get it from the current thread but it’s another matter), use it to CRUD the entity. and return control to the service layer. From this point on, there should be no more interaction with the DB.

Now the “pattern” tells us that if an Hibernate proxy need to access the DB in the presentation layer, well, no problem, we should open the session on demand. This approach has 3 big disadvantages IMHO:

1. each lazy initialization will get you a query meaning each entity will need N + 1 queries, where N is the number of lazy associations. If your screen presents tabular data, reading Hibernate’s log is a big hint that you do not do as you should
2. this completely defeats layered architecture, since you sully your nails with DB in the presentation layer. This is a conceptual con, so I could live with it but there is a corollary
3. last but not least, if an exception occurs while fetching the session, it will occur during the writing of the page: you cannot present a clean error page to the user and the only thing you can do is write an error message in the body

Another variant of this is to use Value Objects and let a mapping framework (such as Dozer) call your proxied getter methods in the service layer. This let you correctly handle errors but your number of queries is still the same.

The best solution I’ve found so far to lazy initialization is the “join fetch” feature in Hibernate, available from both the Criteria API (setFetchMode(association, FetchMode.EAGER)) and HQL (JOIN FETCH). This means your query methods will be aimed at providing a full objects cluster to your upper layers. This also means, and I must confess this is a disadvantage, that your presentation/service layers will leak to your persistence methods: for example, you will have a getCourseWithTeacher() method and a getCourseWithStudents() method where in both cases some relations will be eagerly fetched (the teacher in the first case, the students in another).

Nevertheless, this approach let you do only one query for each screen/service and it lets you cleanly manage your exceptions.

I see only a use case for OpenSessionInView: if you have a bunch of junior Hibernate developers, no time to properly explain them the whole shebang, and no performance issues (perhaps because of a very simple entity model or from very simple screens), then it is a good trade-off (but still not a pattern). As soon as you diverge from this configuration, it will lead you to a world of pain…

I’m interested in having your inputs and arguments about advantages  I may have missed about OpenSessionInView so long as it has nothing to do with:

• I’ve always done so successfully
• I never had any problems
• XXX advertise for OpenSessionInView in YYY book (yes, I know about Gavin King but it shouldn’t stop anyone from thinking on his own). A variant of this is: the ZZZ framework has a class that does it (I know about Spring too)

I’m also interested in other solutions for the LazyInitializationException, if you’ve have creative insights about it.

Whoever is in charge of software architecture, be they senior developers, whole teams like in agile practice or architects-per-se, it is a deep trend to apply what I like to call Ego Driven Architecture (or EDA for short, not to be mistaken with Event Driven Architecture).

When one has to choose an architecture, one should design it from a number of objective criteria, including:

• business requirements,
• technical constraints,
• ease of use,
• maintenance costs,
• etc.

One could even argue you should take care of subjective yet real constraints:

• cross-service warfare (between the development team and the productio team),
• interpersonal problems (between a project manager and the lead developer),
• historical bias (not using EJB3 because EJB2 where too complex to develop),
• etc.

Normaly, each criterion is then assigned a priority, and the designed architecture’s objective is to answer the most criteria, based on their priority. Alas, when using EDA, the top priority criterion is completely different: whatever the constraints and the requirements, the technologies used on the project should make the CV of the architect(s) shine brighter.

If you already don’t know what I speak of, imagine an architect using EJB3 on a project though the production application server is not ready to run them yet. Or an architect pressing the production team to upgrade to the latest version of the application server, although there’s no real need to. I know you’ve already seen such behaviours.

There’re a number of factors that contribute to the thriving of  EDA:

1. There’s no validation of projects architecture by a dedicated technical team. Either there’s no such cross-project team or it has no influence over architectural choices, due to the business funding (read power). Remember that since the money comes from the business, it is always very hard to tell them ‘no’.
2. Architects in charge of the design are junior. They definitely want to put to good use what they read in articles posted on the Web. Not to offense anyone, but before using Scala and such, wouldn’t it be better if someone already had enough feedbacks?
3. Architects are only hired for the time of the project. If your contribution stops when the project is shipped, it is a very big incentive to try unconventional technologies. Try talking with internal IS teams and you’ll find the ‘veni, vedi, vici‘ syndrom a top resentment cause for outsourcing since they usually end up cleaning the crap.

Still, the root cause of EDA is a miscalculation on the architect’s part. The IS world, even globalized, is very very finite. You always work with the same persons. If you practice EDA, sooner or later, you’ll find someone who will remember you for being the one who proposed the architecture who killed the project. Our work is complex enough taking every business requirement, every technical constraint, every service warfare into account without bringing the architect’s ego into the fray. So please, refrain from using EDA

This doesn’t mean you shouldn’t strive to use pertinent technologies in your architecture but it should be based on objective reasons, not you carreer.