Insane Programming Java ramblings and finds on the net

Hibernate’s bidirectional @OneToOne and lazy loading

Just a small post now, about something I discovered when developing a JPA example project concerning one-to-one relationships and fetching them.

Getting Hibernate out of your POJO’s

Anyone using Hibernate for the persistence layer in their program, knows that a JPA POJO contains traces of proxy class types from the Hibernate API. For example, if you have a one-to-many relationship between 2 entities expressed by a List in one of the entities, the corresponding implementation of that list when retrieving that object using Hibernate will be PersistentBag. The same goes for set, respectively represented by a PersistentSet. To-one lazy fetched object references are at runtime replaced with subclasses of the actual entity, which also implement Hibernate's lazy fetching. But so far for basic Hibernate POJO pollution.

In most cases, this isn't really an issue. Unless your transaction is already closed and lazy-fetching isn't possible anymore, in which case you'll get the dreaded LazyInitializationException. In web applications there are workarounds available to avoid this kind of issues, fetching the needed fields if they need to be show on screen. However, there are a couple of cases in which lazy fetching is a bad thing. For example, if you're exposing your entities through a web service, say REST, you need to marshal your entities to an XML or JSON format. In that case, you probably have retrieved the entities with the entities and their relationships you intend to marshal. In most cases, you also don't have an open JPA transaction at that moment. If you did, you would marshall the entire object graph, lazily fetching entities every step of the way, ending up with something possibly a lot larger than you wanted. If you don't, you'll will most certainly run into a LazyInitializationException. The same thing happens if you're using Dozer, mapping between data structures. Or when you just don't want pieces of Hibernate's API on the client side, for example if you're using a client-server architecture. All of this is the reason why DTO's are still present in some JPA-based systems.

After running into the issue more than I would like (in my case, mostly Dozer related problems), I looked to Google for answers. I found some interesting ideas, but none that fit my use cases. I hate the idea of a DTO, but my solutions needs to account for DTO usage. The solution also needed to be a one-size-fits-all with as little configuration as possible (in which case custom mappers were out as they required a lot of configuration). Then, I finally found it, thanks to a post on StackOverflow: tucked away and undocumented in the Dozer API is the support for custom field mappers. I took the solution and used it as a template for a more generic solution. Here it is:

public class HibernateFieldMapper implements CustomFieldMapper {
    public boolean mapField(Object source, Object destination, Object sourceFieldValue, ClassMap classMap, FieldMap fieldMapping) {
        if (!(sourceFieldValue instanceof PersistentCollection) && !(sourceFieldValue instanceof HibernateProxy)) {
            return false;
        } else {
            if(Hibernate.isInitialized(sourceFieldValue)) {
                return false;
            }
            else {
                destination = null;
                return true;
            }
        }
    }
}

It's so unbelievably simple and elegant. You put the custom field mapped on your DozerBeanMapper and voila, no more lazy fetching or LazyInitializationException. Finally a way to get Hibernate out of your POJO and safely be able to marshal a JPA POJO into anything you want.