Skip to main content

Adopting a Java Persistence Framework: Which, When, and What?

December 18, 2007


For developing new software systems, Object-Oriented Programming
is undeniably the most widely used programming paradigm today. For
commercial data persistence needs, the Relational Database Management
System (RDBMS) is the most widely used system of choice. RDBMSes use
a relational model, which is different than the domain object model
of the software system. When your software system is developed
using an object-oriented programming language and data persisted in
RDBMS, a data persistence framework can be a very critical and
important component of your application architecture to hide the
underlying complexity of application data persistence.

Over the years, several persistence frameworks have evolved that
help you manage your object-relational mapping and data persistence
needs. Selecting a framework that suits your requirements is,
however, not a trivial task, because several factors influence this
decision. In this article, I intend to discuss some of the more
widely used Java persistence frameworks against three fundamental
criteria: Which, When, and What. In Which, I will introduce a
framework; in When, I will discuss some of the scenarios when
should you consider adopting it and some scenarios when should you
look for an alternative; and finally, in What, I
will discuss what benefits and what liabilities the framework has
if you decide to adopt it. Let's begin with the following frameworks
that are best known in the Java persistence landscape.

  • Entity Enterprise Java Beans
  • Java Persistence API
  • Hibernate
  • TopLink

Let me discuss these frameworks in more detail.

Entity Enterprise Java Beans

JavaBeans (EJB)
technology is a managed, server-side component
architecture for the Java platform, Enterprise Edition (Java EE). In
this definition, "managed" and "server-side" are the key terms. In
EJB architecture, an "">application
manages the lifecycle of one or more deployed EJBs and
provides common runtime services via an EJB container. Security,
concurrency control, transactions, and persistence management are
a few examples of container-provided services.

The EJB "">specification categorizes
three types of enterprise beans: Session, Entity
and Message Driven. Each type has some distinct
characteristics and is used for different purposes. Since this
article is about Java Persistence frameworks, let me briefly discuss
the persistence aspect of the EJB architecture, which involves
using Entity EJBs to manage the persistence requirements of your
Enterprise Java application.

With EJBs, you can design your application such that an EJB
represents an entity in your business domain model. For example,
think about an Account entity of a commercial banking
application. The Account entity bean will be deployed into
the J2EE application server that will provide several runtime
services to this entity bean via the EJB container. One such
service is automatic persistence, which I will discuss in bit more

Based on how the persistence is achieved, Entity EJBs are
further classified into two categories: Bean-Managed Persistence
(BMP) and Container-Managed Persistence(CMP). With BMP, the bean
instance is responsible for persistence of its state, which is
achieved by JDBC code. With Container-Managed Persistence, the EJB
container provides the ability to automatically manage persistence
of entity beans: saving the state to or loading the state from the
underlying database as and when needed.

Now let's discuss some scenarios where you may want to adopt EJB
framework in general and use CMP for data persistence in

When to Consider Adopting EJB as Persistence Framework
  1. The need for container-provided services is the first thing you
    should consider. If your application needs other container-provided
    services such as transaction management, security, and concurrency
    control in addition to persistence management, then the EJB
    framework is a better choice.

  2. Resource requirement is another factor to consider. The EJB
    framework provides excellent scalability for demanding
    applications. This, however, comes with a price: intensive resource
    requirements, especially with the "">remote
    model. Consider adopting entity EJBs only if there is
    no resource restriction, to achieve the required level of

  3. A de facto framework is another factor in play. If you are doing
    some serious EE development based on the Java platform, then chances
    are that the EJB container is already available as part of your
    application server. "Why not use what is already available?"
    might be the first question asked in your architectural decision-making process. I consider this as a "political" advantage over
    other frameworks, because it is already available.

When to Consider an Alternative to EJB as Persistence
  1. The feature requirements of the persistence layer is the first
    factor that may prompt you to look for an alternative. If your
    application does not require every feature an EJB framework
    provides, then that is the first indication that you should look
    for an alternative.

  2. Resource availability outweighing performance requirements is
    another situation in which you may want to look for another
    alternative. Although it provides excellent performance and
    scalability, the EJB framework is notorious for resource
    consumption. But the bottom line question is: do you really need
    this? A well-written data access object or the Hibernate framework will
    provide an excellent alternative to EJB in many situations.

  3. A data source other than a relational database, although rare,
    would prevent you from using a container-managed persistence

If you are already using or plan to use EJBs as your persistence
framework, here are the benefits and liabilities you can

What Are the Entity EJB Benefits?
  1. The distributed component-based model makes it network-neutral--the EJB components can be deployed in the same JVM that serves
    the rest of the application, or in the JVM of an application server
    located in a different geographical location.

  2. You will achieve excellent scalability: EJBs scale up nicely
    because the container can pool the instances, activating and
    passivating if necessary.

  3. The EJB has been around for long enough to mature as a proven
    technology. Also, it has evolved to provide more useful services and
    features. For example, the timer service is one of my favorites; with it, you can schedule the execution of a job in specific intervals
    (such as nightly, weekly, or monthly). Another nice feature in EJB
    3.0 is Java language metadata annotations support that eliminates
    all required interfaces for entity persistence, and enhancements in
    EJB's query language.

What Are the Entity EJB Liabilities?
  1. The EJB architecture is non-trivial to learn and use. You should
    prepare to learn terms like remote interface, home
    , activation, passivation, and so on,
    most of which are applicable only to the EJB world.

  2. The EJB architecture does not provide persistence independence.
    Since the classes are used in their own way within an EJB
    container, there is no easy way you can take EJB classes and use
    them in another framework.

  3. Achieving an acceptable level of performance for entity beans
    has always been a challenge, especially in the remote interface

Java Persistence API

Right from the time when EJB technology became available for
adoption, there has been general sense of skepticism on its
usefulness in real-world applications. In my view, complexity and
resource intensiveness are two of the most important reasons for
this phenomenon. Consequently, simpler frameworks that have a smaller
resource footprint, like Spring and Hibernate, appeared later than
EJB but gained popularity more quickly. To address this, we have
witnessed a major shift in the direction of EJB 3.0 specification
from its predecessors. Created as part of "">JSR 220, this
specification provides features like "">Plain Old Java Object
(POJO) support, dependency injection, and annotations. A completely
new set of APIs are now introduced as the "">Java
Persistence API (JPA)
to allow developers to manage relational
data from Java EE (or even SE) applications. Further, Sun "">claims
that the Java Persistence API draws some of the best ideas from
the Hibernate, TopLink (both discussed later), JDO, and EJB

Currently, the GlassFish
project provides a reference implementation of the JPA as "TopLink
Essentials," part of the GlassFish application server. You can find
the JPA reference implementation on the "">GlassFish community page. Do
not confuse TopLink Essentials with TopLink, which is the relational
mapping tool currently owned by "">Oracle
. I will discuss the TopLink framework later in this

Let's discuss some of the scenarios in which you should consider
adopting JPA as your persistence framework.

When to Consider Adopting JPA as Persistence Framework
  1. You prefer to adopt a standards-based framework with "nice to
    have" features from popular frameworks like Hibernate, TopLink, and

  2. You need a lightweight persistence framework and don't
    necessarily need EJB's container-provided services.

  3. You need a persistence framework that can be used in a standard
    or enterprise Java application.

When to Consider Alternatives to JPA
  1. The version of Java that you are using determines if you can
    actually adopt JPA. JPA is part of the EJB 3.0 specification, which
    is part of the Java EE 5 release. If you are not up to Java EE 5,
    it is not possible to use JPA.

  2. Your application requires services that JPA cannot provide, such
    as those provided by an EJB container, in which case you are pretty
    much tied to EJB.

Before ending discussions on this framework, let me list some
benefits and liabilities of using JPA as your persistence

What Are the JPA Benefits?
  1. JPA is standards-based. More and more vendors are expected to
    offer the JPA implementation in the near future.

  2. It offers the best features from Hibernate and TopLink.

  3. It can be used with both Java SE and Java EE
    applications, with or without an EJB container.

What Are the JPA Liabilities?
  1. Being fairly new, the JPA specification may go through
    significant evolution before becoming stable.

  2. JPA is a specification instead of a product. You need a vendor
    to provide an implementation to get meaningful advantages from
    these standard-based APIs.


Hibernate is an object
persistence framework that simplifies object-relational mapping
between a Java application and an underlying relational database. It
does so by providing transparent persistence of POJOs, working as a
"mediator" layer to provide automatic persistence and loading of
objects from a Java application to database tables. With Hibernate,
saving object state to and loading object state from a database is
as easy as calling methods in Java objects. You don't have to
manage low-level database operations from your application code;
the Hibernate framework takes care of all the intermediate steps
for you.

Let's discuss some of the scenarios where you would consider
adopting Hibernate as your persistence framework and those in which you should look for
an alternative.

When to Use Hibernate as Your Persistence Framework
  1. You are looking for a simple persistence framework that is easy
    to learn and use. You just need to understand a couple of mapping
    configuration files before you can actually start persisting your
    Java objects into the target database.

  2. You are looking for a highly generic and flexible persistence
    framework. Hibernate is pretty flexible in terms of its usage: it
    can be used with or without an application server, and with or
    without relational database systems.

  3. You don't want to pay acquisition and maintenance fees.
    Hibernate is open source and free.

The Hibernate framework is very compelling for adoption because it
is simple and flexible, yet powerful. However, here are some scenarios
when you may want to consider adopting a different framework.

When to Consider an Alternative Framework to Hibernate
  1. You don't want yet another framework. Although simple, the
    Hibernate framework has its own learning curve, maintenance/upgrade
    cycle, and so forth.

  2. You need container-provided services, such as those provided by
    EJB, in which case your choices are pretty much limited to EJB.

If you are using or plan to use Hibernate as your persistence
framework, here are some of the benefits and liabilities.

What Are the Hibernate Benefits?
  1. Hibernate is easy to learn and use. As I mentioned earlier, you
    just need to understand a couple of simple, self-described
    configuration files before before you can use it.

  2. It is very flexible. You can use Hibernate in any application
    architecture that needs persistence service. You can use it in
    standard Java applications, in Enterprise Java applications with
    servlets, and/or with Enterprise Java Beans. It also integrates very
    nicely with the Spring framework.

  3. It scales up pretty well, as it was designed from the ground up
    to work in a cluster environment. The performance of the latest version
    of Hibernate is also enhanced by techniques like "">lazy
    and optimizing Java reflection via the "">CGLIB runtime byte code
    generation library.

What Are the Hibernate Liabilities?
  1. Hibernate is another framework that has its own adoption and
    maintenance cycle.

  2. Although active community support is available, sometimes the
    absence of a single vendor who specializes in the product makes it
    difficult to influence architectural reasons to adopt this

is another object-relational mapping framework for Java that
provides a powerful and flexible framework for storing and loading
Java objects to and from databases and XML documents. After several
mergers and acquisitions (see a brief history on "">TopLink's Wikipedia page), TopLink has been part of the Oracle Fusion middleware since

In 2006, Oracle donated source code from the TopLink product and
development resources to the "">GlassFish project. This
project was named TopLink Essentials and became the Java EE EJB 3.0
JPA reference implementation. It is a scaled-down version of the
TopLink product from Oracle, missing some features such as cache
synchronization between clustered applications, cache validation
policy, and query cache. Also in 2007, Oracle donated the source
code from the TopLink product and development resources to the open
source "">EclipseLink project.

Here are some scenarios in which you may want to adopt TopLink
as your persistence framework and some of the scenarios where you
may want to look for alternatives.

  1. Although TopLink can be adapted to work with other software
    systems, it is a better choice if your software systems have a
    substantial presence of Oracle software products, because this
    creates a homogeneous software product suite from same vendor.

  1. You are a non-Oracle shop. If you have only a few software
    systems from Oracle, then you may have several other options more
    suited for your needs. This may be fairly typical for EE-based
    application servers because at the time of this writing, WebSphere,
    JBoss, and WebLogic are the top three leading application server
    vendors in terms of market share.

Let's finally evaluate some benefits and liabilities of
adopting TopLink as your persistence framework.

  1. TopLink is the ideal persistence framework choice if your chosen
    software lineup already has a substantial presence of Oracle

  2. It is a pretty mature and time-tested framework, supported by

  3. Advanced features such as cache synchronization between
    clustered applications, cache validation policy, and query cache
    makes it suitable to adopt in applications that are clustered and
    require high performance.

  1. It is proprietary; its future direction is dictated by Oracle.

  2. As with any new framework, it has its own learning curve.

Persistence Frameworks Selection Matrix

Before moving forward, let me summarize in the following table
the frameworks discussed so far. In it you will see a general
context (When), the framework you should consider
(Which), and the benefits and liabilities you get
(What). You should consider these as the starting points
for the process of selecting persistence framework. Your final
selection should be based on these and other application-specific
requirements, if any.

"Persistence Frameworks Selection Matrix">
(Consider adopting)
(If your application needs)
What benefits?
(You will get these benefits)
What liabilities?
(You will get these liabilities)
Java Persistence API Simple persistence framework for standard or enterprise Java
  • It is standards-based
  • It incorporates several "nice to have" features from other
  • It is a specification: you need to adopt an implementation from a
    specific vendor
  • It cannot be used with versions of Java earlier than 5.0
Container-managed Entity EJB Container-provided services such as security and transaction
management, in addition to persistence management
  • Distributed component-based
  • Nice scalability
  • Resource-intensive
  • Complex to learn and use
  • Less flexible
Hibernate You want a simple, flexible framework
  • No acquisition or maintenance fees
  • Integrates nicely with other frameworks
  • Easy to learn and use
  • Flexible: can be used with or without EJBs, in standard or
    enterprise Java applications
  • Open source
TopLink Your software systems already use a substantial amount of
Oracle products
  • Mature technology
  • Vendor-specific

Other Persistence Frameworks

Before summarizing, let me list some other persistence
frameworks worth exploring before you actually adopt one. More
detailed discussion on these frameworks is beyond the scope of the article.


It is obvious that which persistence framework you will adopt
for your next Java application will be influenced by several
factors such as features required, acquisition and maintenance
costs, and non-functional requirements (its maintainability,
performance, etc). Several proprietary and open source frameworks
are now available, each with its own advantages
(benefits) and liabilities (weaknesses).

In this article, I've presented some of the more popular Java
persistence frameworks in terms of three criteria: which (defining the
framework), when (when should you consider adopting and when should
you look for an alternative), and what (what are the benefits and
liabilities) of adopting it. The scenarios presented in this
article are intended to assist you make a more informed decision
before you actually select a framework for adoption. Therefore, you
should adopt your next Java persistence framework based on the
criteria discussed in this article in addition to other current and
future needs specific to the application.


width="1" height="1" border="0" alt=" " />
Sharad Acharya has more than eight years of experience in the software engineering field in multiple business domains including supply chain, insurance, banking, and mortgage.
Related Topics >> Databases   |