Hibernate anti-pattern #1 – hashCode/equals

I've been doing a lot of Hibernate refactoring and performance tuning at work lately and have been spending time wrestling with some interesting anti-patterns that have crept into the code. One is our particularly bad hashCode/equals implementation which has some pretty frustrating implications¹.

There's a lengthy discussion here about various ways to implement hashCode and equals for Hibernate-managed entities. The post is great, and the discussion in the comments is also good.

The assumption is that the 1st-level cache (and also the 2nd-level cache if implemented) ensures that instances are unique. So our base entity class has a final equals method that uses the same logic as Object - two instances are equal if they're the same (==). Likewise, hashCode is final and returns System.identityHashCode(this), the same value as if the method weren't overridden (we have a base class between Object and our base entity class that necessitates explicitly reverting the behavior to that of Object):

This turns out to be overly simplistic and optimistic - it sure would be nice if that's all it took, since there's no equals/hashCode maintenance for new entity classes, no custom entity-specific logic to implement.

If you call Foo foo1 = session.get(Foo.class, 123) and Foo foo2 = session.get(Foo.class, 123), the 2nd call will return a reference to the cached 1st instance - there's only 1 database hit. This is one of the primary benefits of using an ORM framework like Hibernate - there's some overhead in its approach but optimizations like this will tend to far outweigh the costs as long as you're using the framework appropriately.

So in this case, foo1 == foo2, and the equals method works fine.

But if you mix eagerly loaded entity instances and proxies, weird things happen. For example, suppose Bar has a lazy many-to-one reference to Foo (or a lazy-loaded collection of Foos); == will always be false even if the target entity of the proxy is the same as the non-proxy instance:

The result is that data access implementation logic has bled up past the service tier and into the web tier; the web tier shouldn't have to be aware of proxies but now has to be. If there's any risk of comparing proxied and non-proxied instances, we have to use primary key equality to test instance equality instead of the much more natural equals.

What's worse, we can't mix persistent and new entity instances in collections that maintain uniqueness (Sets/Maps). A new instance can never be equal to a persistent instance even if every non-pk property value is the same, so we again have to deal with the data tier bleeding into other tiers and jump through hoops to get Set uniqueness and contains to work.

So here's my proposed approach. Comparing two persistent instances using primary key is very efficient since primary keys are unique. This doesn't help when comparing persistent and new instances though, and is inappropriate for usage in hashCode for the reasons discussed in the Hibernate post referenced above. Specifically, the hashCode will change from whatever you use before the instance is persisted to the primary key (or some value derived from it) afterwards. This will confuse hash-based collections since the instance will most likely be in the wrong hash bucket and cannot be found.

So equals compares primary keys if both are non-null. If either is null, then the class must define the fields that determine uniqueness and compare those.

hashCode always uses the same fields used in the equals comparison and never the primary key. If the entity is immutable or the fields that are used for the calculation are, then the hashCode could be cached to save the cost of unnecessary recalculation.

Most of this logic is in the base entity class, with abstract methods that force each entity class to define entity-specific behavior:

A concrete subclass must implement getHashCodeData and dataEquals, for example using the username property for a User class:

This has worked well so far. It's consistent, even when an instance transitions from new to persistent and its primary key becomes non-null. The data used for hashCode calculation never changes, so that's consistent. The data for equals does change, but it stays consistent - comparing two persistent entities or mixing persistent and new returns the correct result in all cases since non-pk data is used for comparison.

Note that equals is final but hashCode isn't to allow caching.

My original implementation of this was way too simplistic, just using the Jakarta Commons Lang reflection methods that I described here. This approach is great for regular value objects and DTOs, but is way too expensive for Hibernate entities since every field is used, even collections and the primary key. Lazy-loaded collections will be retrieved from the database to calculate hashCode and equals, which is almost always inappropriate.

So I worked on a slightly smarter approach that skipped the primary key and collections but still used reflection for the rest of the fields. This is still too expensive, and breaks when using proxies since the fields will be null - the getter methods delegate to the data that's in the proxy's target instance.

Eventually I ended up with the current implementation, which has lasted for a while with no issues.

1. Ironically, The Decider^tm was asked recently why this choice was made and he couldn't defend it, but was sure that there was a good reason for it and wasn't willing to change anything even given the implications of the decision.[back]

This entry was posted on Friday, December 14th, 2007 at 12:30am and is filed under hibernate, java. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response (comments are moderated) or trackback from your own site.