Advanced Hibernate: Proxy Pitfalls

Maarten Winkels

Most programmers come into contact with Hibernate proxies when they face the ominous LazyInitializationException. The bad taste is hard to wash away, but Proxies are a necessary “evil” when working with Hibernate. This article will dig into why proxies are important. It will also point out some pitfalls that occur often when working with proxies.

What are proxies?

Proxies are the mechanism that allows Hibernate to break up the interconnected cloud of objects in the database into smaller chunks, that can easily fit in memory.

Let’s look at an example.

1 Daan NULL
2 Vincent 1
3 Eelco 1
4 Jan 2
5 Maarten 3
6 Erik 3
public class Person {
  private Long id;
  private String name;
  private Person boss;
  private Set employees;

This is a very simple example. The class on the right is mapped to the table on the left. So what happens if Hibernate loads the row with NAME=’Maarten’? To store the data in memory, Hibernate will create a new Person object and set the columns to the fields. It stores the ID column in the id field and the NAME column in the name field.

Coming to the BOSS column, Hibernate faces a problem: The type of the column is NUMERIC, but the type of the property is Person. This is of course a foreign key, to another row in the PERSON table. Now, Hibernate could simply load the data from the associated row and create a new Person object and store it in the field, but this would cascade eventually to all rows in the table (and possibly other tables in the database), especially taking into account the employees property as well.


Instead of loading the associated row, Hibernate will create a Person object and set the id property to the value found in the BOSS column. This Person object is a specialized Person object, that will load the associated data if necessary. Initially the fields of this new Person object are not set, since the data is not yet loaded. When a method is invoked on the object, Hibernate will fetch the data from the column and populate the object. This is the proxy mechanism.

To add this new behavior (the loading of the data when a method is invoked), Hibernate will create a dynamic subclass of Person using CGLib and add the desired functionality. We need a subclass of Person here, to comply with the type of the boss field.


So what does this look like? Looking at a proxy in a debugger is quite interesting. To the left you find an image of the eclipse debugger displaying a Person object loaded from the database, with the boss property set to a Hibernate proxy. A Hibernate proxy can be easily identified by the class name, which will contain the "$EnhancerByCGLIB$" marker. This is due to the fact that the class is generated at runtime by CGLib.

The proxy class is a subclass of the Person class, so it contains the same fields (as can be seen in the debugger), but it also contains some added fields. The most important is CGLIB$CALLBACK_0, which is set to an instance of CGLIBLazyInitializer, which is a Hibernate class. This is the object that enables the proxy to load the data when needed. It contains a "target" field, that will contain the Hibernate loaded object when the data is loaded.

In the debugger, we can do funny things with this proxy. By clicking the proxy itself, the debugger will invoke the toString() method on the object, effectively loading the data itself, and setting the target field in the LazyInitializer to a Person object with the data loaded. This can change the behavior of applications and unittests severely! The same holds by the way for Hibernate collections that are not yet loaded; clicking it in a debugger will load the collection.

Proxy Pitfall 1: Field Access

Coming to the first pitfall with proxies: When a proxy is loaded, the data is not stored in thr proxy object, but in the "target" object. The fields in the proxy object will remain null forever (or any value that they have been initialized with), since all methods invoked on the proxy will be delegated to the target object.

The main area where this Pitfall arises is the equals(..) method. A very common implementation would be something like this:

  public boolean equals(Object obj) {
    if (obj == null) {
      return false;
    if (obj == this) {
      return true;
    if (!(obj instanceof Person)) {
      return false;
    return name.equals((Person)obj).name);

checking the name field of the two Person objects to be the same. This will fail however when we invoke it like personObject.equals(personProxy). In the last line of the method we use direct field access on the other object to look at the name field. Since the other object is a proxy, the field will always be null, even if the proxy is in fact encapsulating the personObject itself. Although the equals(..) method is a typical problem area for this pitfall, it is definitely not limited to that. Every method that takes the declaring class as parameter (and thus allows access to fields on that parameter) has the same problem.

To prevent this, use getters and setters in these occasions. The proxy will be loaded when the getter is invoked and the data will be accessible.

Proxy Pitfall 2: instanceOf


A proxy will be a subclass of the field type that is required. Hibernate will look at the type of the field and create a dynamic class with that type, adding the necessary functionality. This means that if the field type is not the actual implementation type, but an interface or superclass, the type of the proxy will be different than the type of the actual object: If the field-type is the superclass of the actual implementation, the proxy-type and the implementation-type will be siblings in the type hierarchy, both extending the superclass.

The proxy object will thus not be an instance of the implementing type, application code depending on this check will fail.

To prevent this pitfall, switch of proxying for the hierarchy, by setting lazy="false" on the top level class. This will prevent Hibernate from using the proxy mechanism and always load objects of this type or subtypes.


Proxying is one of the most important features of Hibernate. Although it takes some time to see its importance and to work with its features, doing so will help you develop applications with Hibernate more easily. Keeping in mind the two pitfalls that are discussed in this blog will prevent hard to find bugs in your applications.

Comments (25)

  1. Martin - Reply

    March 9, 2008 at 2:08 pm

    Nice article. Thank you.

    I was aware of the first pitfall you mentioned (I actually ran into that problem once and it took me half a day to find out what's going on), but I've never wasted a thought on the instanceof operator pitfall in case of the reference type being a supertype of the actual implementation. That's really useful information. Thanks again.

    But regarding your solution for preventing this pitfall: Settings lazy="false" on the top level class will disable the proxy mechansism for each and every to-one relationship to this object. I think that should be kept in mind...


  2. Peter - Reply

    March 9, 2008 at 10:01 pm

    Another problem caused by proxies is that you are forced to write an equal/hashcode for entities!

    If proxies were not possible, the default equals/hashcode of Object will do because you never want to have multiple instances of the same entity in a single session. So why be bother with writing an equals/hash (usually based on arguments that can change, so the equals/hashcode is broken).

  3. fletch - Reply

    March 10, 2008 at 1:38 am

    Another pitfall is when you want to detach the objects. In a web application it means having to use something like the OpenSessionInViewFilter which has its own problems, using Hibernate.initialise() all over the place (which gets messy if your domain objects are all connected to each other) or, finally, copying your domain objects to DTO's that are a view on the domain objects. *sigh*. I can see why the hibernate team uses proxies but it is painful.

  4. Maarten Winkels - Reply

    March 10, 2008 at 9:57 am

    @Martin: Thanks for your response! Setting lazy="false" will indeed load extra data for every fetch on a referring object, which could be a performance problem. Good catch!

    @Peter: Actually, you don't need to write equals/hashcode for proxies for that reason: Hibernate will enforce that every entity is represented by a single instance in a session, also for proxies. It will lookup a proxy instance if needed in an internal map, that is bound to the session.

    @Fletch: This is not really a pitfall, but an artifact of why proxies are needed: Hibernate cannot load all data in one go. You have to configure Hibernate to stop loading data at the correct junctions in your domain model. Using the Hibernate configuration, you can already configure classes or associations to be eagerly loaded (either by join or by separate select), which means you don't have to use Hibernate.initialize(..). A new feature (that I heard Emmanual Bernard talk about during Grails Exchange) is fetch groups. This would make it possible to configure explicitly which associations should be loaded in which situation.

  5. Medhat Saleh - Reply

    March 11, 2008 at 3:05 am

    Thanks a lot for these two. I was bitten before by the second one and could not figure out how to solve cleanly as you are suggesting, so I ended up with a very nasty hack in the domain code.

  6. Cédric Thiébault - Reply

    March 26, 2008 at 6:15 pm

    To know the class of the proxy object, you can use the method
    Class getClassWithoutInitializingProxy(Object object)
    * Get the class of an instance or the underlying class
    * of a proxy (without initializing the proxy!). It is
    * almost always better to use the entity name!

  7. koensen - Reply

    April 16, 2008 at 5:57 pm

    Actually there are some architectural problems resulting from pitfall 2.
    There are some cases where you don't want to expose a (visible) setter which could initialize the object...
    Read here:

    A pretty neat workaround some things is to work with get() instead of load().

  8. Christian - Reply

    June 9, 2008 at 11:46 am

    my 2 cents:
    pitfall #2 is just a design/implementation bug, where Hibernate has never admitted, that it is a bug Hey, its the world best ORM and everything else is crap

    The JPA spec has addressed this: 2.1.7. ...Relationships are polymorphic.
    Nothing more to say, except that it sometimes does still occur in Hibernates JPA implementation (but now its a bug, not a feature)

    Regarding Proxies in general: The Hibernate approach is the we-can-implement-it-on-a-weekend approach. Whereas JDO has featured a smarter approach (available in many JPA implementations), i.e. use byte code enhancement to implement the proxy functionality in the class itself, which solves most of the problems. (But you can't design and implement that on a weekend.)


  9. Christian - Reply

    June 9, 2008 at 11:47 am

    my < and > got lost, it should read:
    <sarcasm>Hey, its the world best ORM and everything else is crap</sarcasm>

  10. Frits Jalvingh - Reply

    September 25, 2008 at 2:27 pm

    Bytecode-enhancing the actual class would be great but in runtime is hard to do because they need to be enhanced before they are ever used which is complex.

    A simpler alternative is to create a proxy for the actual object itself and *not* have the "target" kludge. Simply use the fields in the proxy directly. This still does not properly solve the inheritance scheme but that is impossible with lazy loading anyway.

    The simpler alternative has way less problems than the current implementation and *can* be built in an afternoon (my replacement for Hibernate called SPF has it, and it took that long 😉

    Sadly, Hibernate sucks bigtime and is not a good persistence framework at all; it is just the one that sucks the least...

  11. Pravin - Reply

    December 4, 2008 at 11:51 am

    Hi I am having problem with same with proxy i want to check whether it is the instance of a class out of two classes as the object is of Base class Like: C is base class and A,B are derived so i want to check whether new C() instanceof A or B.

    Please help me


  12. [...] when invoking the identifier getter method. My colleague Maarten Winkels has blogged about the pitfalls of these Hibernate proxies last [...]

  13. donamir - Reply

    October 21, 2009 at 11:12 am

    Useful article, tanks.

  14. [...] the lazy proxy is NOT the same as the actual object. If you depend on the datatype of the object, you may have problems, since the type of the proxy isn’t the same as the type of the actual object (e.g. a proxy [...]

  15. Sean van Buggenum - Reply

    September 14, 2010 at 3:25 am

    Hi all,

    I am just now revisiting hibernate, and came across this great, helpful blog. Thanks.

    However, I do have a question. I know this was written 2 years ago, but I hope someone can anyway clear this up for me.

    I would like to question "Proxy Pitfall 2: instanceOf".

    When one has a class A,
    and a class B extends A,

    one can correctly assert the following:

    A aObj = new A();
    B bObj = new B();

    assertTrue(aobj instanceof A && bObj instanceof A);

    This should pass, because while bObj is not an exact instance of class A, the operator 'instanceof' evaluates as true of an object is an instance of the specified class OR an instance of a subclass of the specified class.

    So, in other words, the 'instanceof' operator causes no problems in testing that an object (which is probably a proxy object) is an instance of the derived class, because it will be.

    So, given this is true, can I assume that the problem mentioned here is more a problem of testing exactly that an object is of a the exact class A (through testing class equals ) ?

    for example:


    which will indeed fail.

  16. Stephane - Reply

    November 20, 2011 at 8:33 pm


    I have a similar issue I guess, related to the proxy mechanism I suspect.

    It is described on the Hibernate forum.

    I wonder if any of you guys would see something interesting in it.

    Thanks !


  17. Stephane - Reply

    December 8, 2011 at 5:45 pm

    Nice article. Thanks for that. Just a little spelling mistake: thr proxy

  18. [...] Oba poprzednie rozwiązania są obarczone tym samym problemem:, metoda equals() sprawdza czy klasy obu obiektów są identyczne, dlatego metoda equals() zwraca false. Dodatkowy problem to odwoływanie się do pól w metodzie equals() a nie do metod, co szerzej opisane jest na blogu Xebia. [...]

  19. Hesham - Reply

    April 29, 2012 at 12:51 pm

    Thanks for this very informative article. It is encouraging to see how different JPA providers solve this problem, specially EclipseLink.

  20. Sebastian - Reply

    November 19, 2012 at 2:44 pm

    Another lesson might just as well be: always have lazy=false AND (be ready to or actually do) detach (i.e. evict()) after loading (makes sense anyway when there is a GUI)
    Means: accept that some associations have to be filled by manual query. It would at least produce a KISS situation

  21. […] such language and bytecode transformations will lead to robust results. People have criticised Hibernate’s use of proxying in various blog […]

  22. […] should still access those values through methods. Otherwise you will fall into the first of the Hibernate proxy pitfalls mentioned by my colleague Maarten […]

  23. Ram - Reply

    September 14, 2015 at 11:38 am

    Nice detailed article ! Thanks

  24. sLoPPydrive - Reply

    September 21, 2015 at 2:47 pm

    I encountered another problem with Proxy Pitfall #1:

    If you have any public methods on your entity that are declared final they cannot get overridden by a proxy method that delegates to the target object. Instead it works on the fields of the proxy class which are all null.


    public class Domain {
    private Long id;
    public final boolean isPersistent() {
    return id != null;

    public class MyEntity extends Domain {

    MyEntity e = // lazily loaded entity, so definitely persistent!
    if (!e.isPersistent()) {
    System.out.println("This is WRONG! The entity IS persistent!");

    The reason isPersistent() doesn't return true is that the method is declared final and thus not substituted by the proxy class. Here you have the Proxy Pitfall #1 scenario but with your own fields instead of fields of a different object (like with "equals").

    Fix by using accessors or (in this case) remove the "final" modifier.

  25. Aysha - Reply

    October 21, 2015 at 11:45 am

    Nice article!! Thanks 🙂

Add a Comment