hosted by
SourceForge.net Logo
| Home | News | Getting started | Overview | Hibernate-GWT issues | FAQ | Thanks |

The Hibernate-GWT lazy issue

The problem

Partial loading of POJO with Hibernate is a current usage to prevent loading of unnecessary data. The persistence library deals with these unloaded associations by handling proxies.

Trying to pass such a partially loaded POJO to GWT will raise an exception, since the Java->Javascript compiler is not able to serialize the nested proxies.

So you cannot send a partially loaded Hibernate POJO to the GWT client side.

The general solution: Data Transfer Object and Dozer

The current common solution to this issue is to use Dozer to clone the Hibenate POJO. It partially solves  the type issue but raises a new one on partially loaded POJO.

Depending on the Hibernate session state (open or closed), Dozer will load the entire POJO association graph or raise a LazyIntialisationException. Indeed, by default Dozer tries to clone all properties: if the session is opened, they are lazy loaded, otherwise Hibernate throws an exception.

Well, the workaround mostly used is to define clone configuration with Dozer that only copy the loaded associations:


This solution works, but it poses some issues:

  • Your project will have to deal with 2 different object hierarchies: the Domain One and the DTO one.
  • You will have to write as many clone configurations that you have of partial load request! This can really become a pain when your project deals with many data tables and as many partial loading request.
  • You have to create as many service entry points as you have DTO concerned by it, even for the same purpose!
public void updateUser(UserWithAddressDTO user) {…}
public void updateUser(CompleteUserDTO user) {…}
public void updateUser(SimpleUserDTO user) {…}

Our solution: Domain Driven Design and hibernate4gwt

The goal of the library is to allow you to send your Domain model to the GWT layer. This is achieved by dynamically cloning the Hibernate POJO. Proxy associations are first marked and then replaced by null to prevent LazyInitializationException or the Javascript compiler exception.

h4gwt clone

The clone POJO can be manipulated by the GWT layer painlessly.

For update, the clone POJO must be merged with an existing Hibernate one to prevent lazy associations to be replaced by null (which would lead Hibernate to delete the association instead of leaving it unchanged).

h4gwt merge

The hibernate4gwt can store and restore seamlessly the Hibernate POJO in the HTTP session (stateful mode) or load a fresh new Hibernate Pojo before merge (stateless mode).

Copyright 2007. All Rights Reserved
 Last updated : 31 may, 2007