Hibernate still leads the way with search, envers and multitenancy support

A great deal of features have been added to the JPA 2.1 specification, but Hibernate still leads the way with features surrounding search, envers and multitenancy support.

Why would an application architect who is designing a modern, enterprise application ever want to use the implementation specific Hibernate Session when they could just as easily choose to use the standards compliant, Java Persistence API EntityManager?

We have something quite cool called Hibernate envers. Just by using an annotation, we literally store every change that happens to an entity.

Emmanuel Bernard, 
Data Architect. 

The EntityManager is part of the JPA standard, and as such, is not implementation specific. By using JPA and the EntityManager, the data layer is much more portable, providing the ability to plug in and pull out the underlying implementation, be it Hibernate or OpenJPA or Data Nucleus, if ever the need arises. Furthermore, when people compare Hibernate vs JPA, they note that JPA is part of the Java EE specification, and Hibernate isn't, so by using JPA and the EntityManager, your code is more philosophically compliant with regards to enterprise Java development. It's a similar comparison between Hibernate vs JDBC.

"From a team point of view, we wish we only had one API," said Emmanuel Bernard, a Data Architect on the JBoss Hibernate team,  when asked about which implementation people should be using in their modern applications. "We encourage people to use the EntityManager."

But the situation isn't as cut and dry as spectators to the debate might think. The fact is, there are compelling reasons why an application might want to leverage some of the features of the Hibernate Session. The Hibernate Session provides JPA compliance, but since it is not limited by the specification, there are many things the Hibernate Session can do that goes above and beyond the spec.

Java persistence and multitenancy support

So, why might an enterprise developer need to go beyond the specification and defer to the powers of the Hibernate Session, along with other elements of the Hibernate Core distribution, instead of just using JPA and the EntityManger?

"I would say the big, shiny one is multitenancy" said Bernard. "Multitenancy almost made it into JPA 2.1, but only in a limited way." Sadly, JPA 2.1 support for multitenancy is by no means a one-size-fits all JDBC solution. "You have several ways to do multitenancy. It can be column discrimination based, it can be done using different schemas, it could be done literally using different physical databases and so on, but only one of those use cases was included in the JPA 2.1 approach." In contrast, the Hibernate Session provides support for a variety of different approaches beyond what was adopted by the expert group.

Versioning with Hibernate envers

"We also have something quite cool called Hibernate envers," said Bernard.  "It is about historical data. Just by using an annotation, we literally store every change that happens to an entity. You can go back in time and say 'what was the state of my database three weeks ago' or 'when did the stock price change from below twenty dollars to above twenty dollars.' We don't change your schema, we just create companion tables that contain the historical data."

And what is really compelling about envers is the fact that other than the annotation added to the entity, the process proceeds transparently, with very little impact on the runtime usability and performance of the applications.

/* Class using the Hibernate envers @Audited annotation */
@Audited // that's the important part :)
public class Person {
    private int id;

    private String name;

    private String surname;

    private Address address;

    // add getters, setters, constructors, equals and hashCode here

Data retrieval and Hibernate search capabilities

Finally, the full text searching features available from the Hibernate Core distribution go far beyond anything that is even discussed by the JPA specification. "Full text search, the ability to literally use Lucene's strengths and capabilities, but on top of your entities, while keeping the object level abstractions" is another feature of which Bernard wants more people in the community to be aware. Persisting data is really only one half of the equation. After all, what is the point of maintaining peta-bytes of data if the searching and retrieval mechanisms are sub-par? Hibernate Search is the often forgotten variable that balances the JDBC and ODBC data persistence equation.

It always makes sense to stay as JPA compliant as possible, but that doesn't mean there aren't compelling reasons to go beyond the specification and utilize various Hibernate specific features, with envers, multitenancy and search three key use cases smart enterprise data architects need to consider.

What is your favorite Hibernate features that is not currently part of the JPA specification. Let us know.

Dig Deeper on Core Java APIs and programming techniques

App Architecture
Software Quality
Cloud Computing