To JPA or not - an introspection on the Java Persistence API

One fine day I was looking into the object persistence architecture we utilize in my project. We use a simple Hibernate based persistence, connecting to our database through JDBC, using JDBC’s transaction semantics. Then i came to thinking is there any advantage of using JPA over Hibernate as opposed to plain old Hibernate. Here are some of my thoughts. Let me start off by talking about persistence, hibernate and JPA in general.

What is persistence?

The general idea behind persistence is to extend an object’s life span. There are technically many ways to implement this. A simple way is to simply store the object as a file on the disk and then convert it back into an object, a good example of this is persisting objects as XML. Another alternative is using a database to store the data. The decision on which kind of persistence to implement basically depends on the kind of functionality that you need to implement. In my project we use both database based persistence and file based persistence (we use XStream , which is again a story for another day)

Let us consider persistence with a database perspective. Traditionally databases follow a relational paradigm. A Table is the main actor and is related to other tables through a relation. But an Object on the other hand compromises an entity along with methods that operate on the entity and it’s association with other entities. This has led to an object relation impedance mismatch which makes it tough to convert between those two.
Say hello to Hibernate and JPA!!

Hibernate has filled this void albeit not perfectly but enough to do the job. Persistence frameworks
is the key behind object relational mapping. Hibernate so far used to do persistence with it’s own Core API. EJB 2.1 was on the wane, a bloated technology, losing it’s grandeur, then came the redesign and scripting of a new reign of a new technology, EJB 3.0 specification that provided the JPA specification as it;’s answer to the entity beans of old.  Hibernate 3.0 has to adapt to this changing world and adopted the JPA specs as it’s own.

JPA essentially provides a POJO based persistence model. It replaced entity beans which had the following problems:
- too heavyweight and coupled to the application server itself
- difficulty in deploying and unit testing

JPA essentially provides a standardization to the persistence methodology. Thus allowing any persistence framework to be used underneath JPA without having to worry about too much configuration. Hibernate implements the JPA specification by creating a wrapper over the Hibernate Core. This wrapper can be further made more effective by introducing annotations to take out some of the responsibility of the configuration file.

When thinking about the JPA specs, we introduce Hibernate EntityManager which is used to define the JPA life cycle rules for persistent objects, and is used as a wrapper around HibernateCore. The advantage of using JPA is that it brings with it some portability when having to switch between application servers that support JPA, which may not be possible with a Hibernate based solution.

JPA has many components that can be somewhat mapped to Hibernate:
EntityManagerFactory –> SessionFactory,
Persistence class creates the EntityManagerFactory,
EntityManager –> Session,
Query –> Query,
EntityTransaction –>Transaction.

It only needs a persistence.xml in the  classpath which configures basic hibernate connection properties.
Everything else is managed through Annotations (for ex. a PersistenceContext injects a EntityManager object into the bean).

The advantage of using Hibernate with JPA is that you can enabled several features of Hibernate without having to mess with the  JPA configuration like for example a second level hibernate cache. In addition to this you can use native hibernate mapping and API,  the only problem with this is that if you decide to use a different JPA provider, it’s gonna get dirty.

Ex 1: If you want to export the schema programmatically, then use a Hibernate Ejb3Configuration()
that can easily replace the EntityManagerFactory, which can yield a AnnotationConfiguration that can
be passed into the SchemaExport instance.

Ex 2: Use the SessionFactory if you need programmatic control over the
second level caching. This can be done by fist casting EntityManagerFactory into
HibernateEntityManagerFactory and then extracting the SessionFactory.

But using JPA also has some disadvantages
* no control over cascading behaviour
* no indexed collections,
* Hibernate provides Filters and Caches
* no collections of primitive values

How useful would JPA be for me in my project?

This is an interesting question. One reason for the shift to JPA could be the standardization aspect, with increased portability. Now we no longer need to worry about moving to a different persistence provider like Hibernate or JDOLink, a concept called pluggable persistence providers. Now the question do I need it for my work? Is it worth sacrificing some of the features of hibernate like cascading and indexed collections for a standardized interface. For now i dont think so, but in the future if we decide to move to a full fledged application server like JBoss, most likely.

Some reference links for this particle post

http://asrijaffar.blogspot.com/2007/01/native-hibernate-vs-hibernate-jpa.html
http://maestro-lab.blogspot.com/2007/09/coding-java-persistence-jpa-vs.html
http://www.javaworld.com/javaworld/jw-07-2008/jw-07-orm-comparison.html
http://clarkupdike.blogspot.com/2007/01/hibernate-mappedby-to-superclass.html

Tags: jpa, persistence