Comment lines: Really, why Hibernate?

IBM® WebSphere® Application Server provides a complete JPA solution based on the Apache OpenJPA project. Although the use of alternate JPA providers, such as Hibernate JPA, is doable, the question remains: "why?" This article explains why the continued use of the WebSphere JPA solution always makes the most sense. This content is part of the IBM WebSphere Developer Technical Journal.


Kevin Sutter (, Senior Software Engineer, IBM

Author photoKevin Sutter is a Senior Software Engineer in the WebSphere Application Server development group. He is currently the lead architect for the Java Persistence API solution for WebSphere Application Server. Kevin is also a committer and a member of the PMC for the Apache OpenJPA project. Kevin's past roles include leading and architecting the WebSphere solutions for J2EE Connector Architecture (JCA) and WebSphere eXtremeScale (caching framework).

25 August 2010

Also available in Chinese

You already have the JPA implementation you need

I have been responding to several forum posts, e-mails, instant messages, and phone calls recently concerning the use of Hibernate within the IBM® WebSphere® Application Server environment. Because there is so much interest in this topic, I thought it would be helpful to those of you who haven't been able to ask me yet in person to document this information here.

Specifically, I am referring to the use of Hibernate JPA in the WebSphere Application Server environment. There is also the original Hibernate programming model, which I refer to as Hibernate "Classic." Since the classic Hibernate programming model is not part of the Java™ EE 5 suite, it’s not that pertinent to this conversation. There have been several iterations of this article which documents how you can utilize the Hibernate "Classic" programming model within the WebSphere Application Server environment. This usage is basically like any other utility framework. You can package it as a (shared) library and use it from your application, but it’s not an integral part of the overall application server runtime.

What this article will focus on is the use of Hibernate JPA in the WebSphere Application Server environment -- or, rather, why use Hibernate JPA at all when WebSphere Application Server already provides an industry-leading JPA implementation?

What is JPA?

JPA is the Java Persistence API. It is the standard persistence framework first introduced as part of the EJB™ 3.0 family of specifications in Java EE 5. For Java EE 6, JPA 2.0 graduates to its own JSR. At its core, JPA is an Object/Relational (O/R) Mapping facility, but it has evolved to include several other features. Because JPA is an integral piece of the Java EE suite, its capabilities are fully integrated with the EJB container and Web container, as well as transaction management, database connection management, and security management. Many technologies fed into the creation of JPA, such as EJB CMP, JDO, and Hibernate. It is no wonder, then, that so many existing Hibernate users want to continue to use this framework within the WebSphere Application Server environment.

The continued use of Hibernate is arguably a valid objective, as moving from one programming model (classic) to another (JPA) takes time and resources. If insufficient justification exists to make this investment, then staying with what works is fine and possibly even encouraged.

But if you are planning to migrate to the JPA standard and enjoy those benefits, then there are several considerable reasons for migrating from Hibernate "Classic" to the WebSphere JPA solution.

WebSphere JPA solutions and advantages

WebSphere Application Server JPA solutions are built upon the Apache OpenJPA project:

All these deliverables utilize the same binaries as are available from the OpenJPA download site, and so you can be assured that any applications written against Apache OpenJPA will continue to run without modification in the WebSphere Application Server environment.

Of course, WebSphere Application Server also has additional features beyond the base OpenJPA deliverable via defined plug points to provide a very complete, very rich JPA solution.

  • Ease of use

    The WebSphere JPA solution is fully integrated into WebSphere Application Server offerings. Whether your environment uses one of the feature pack solutions or WebSphere Application Server v7, the JPA solution is ready to use out-of-the-box with no additional configuration or packaging required.

    Because of this integrated JPA solution (Figure 1), WebSphere Application Server is able to provide functional extensions to the base OpenJPA binaries. Some of the areas that have been enhanced are IBM DB2® extensions (specifically pureQuery integration and locking optimizations), performance, configuration and admin support, security support, extended trace and logging support, and national language support for message logging.

    Figure 1. WebSphere JPA architecture
    Figure 1. WebSphere JPA architecture

    WebSphere Application Server JPA solutions enable alternate JPA providers to be installed and used with the WebSphere Application Server runtime. For example, the use of Hibernate JPA is possible, but none of the WebSphere Application Server extensions will be available with the Hibernate JPA provider. Beyond that, the packaging of the Hibernate JPA solution is not trivial (see Resources). The bottom line, therefore, is that WebSphere Application Server does support the use of alternate JPA providers, but there are drawbacks to this approach.

  • Lower support costs

    The complete WebSphere JPA solution has full IBM product service and support, which means that any problems discovered will be addressed via normal support channels. Most members of the JPA development team are active committers on the Apache OpenJPA project. Issues will be logged and resolved with the Apache OpenJPA project. These updates will then conveniently be delivered as part of the normal WebSphere support process.

    Another major advantage of a WebSphere JPA solution is release-to-release compatibility support. It is important that migrating from one WebSphere Application Server release to the next – including full versions and feature packs – be as easy as possible, and every attempt is made to make the JPA migration painless as well. Should a new JPA or Java EE specification force incompatible changes to be made to the product, documentation and "back out options" to achieve the prior behavior are typically provided. Because of the flexible packaging architecture of OpenJPA, WebSphere Application Server can override any non-conforming behavior of OpenJPA to make the WebSphere Application Server experience consistent from release to release.

    If you use an alternate JPA provider, such as Hibernate JPA, then WebSphere Application Server support stops at the defined plug point for the alternate JPA provider. Any problems discovered in the alternate JPA provider (such as object mappings, database interaction, performance concerns, and so on) will need to addressed with that provider. This might involve using their forums for support or establishing an external service contract. Clearly, not a convenience.

  • Better performance

    For the record, performance comparisons can be tricky. Any performance benchmarks that are developed and promoted by a JPA provider -- even so-called "independent" JPA benchmarks that get posted to the Web -- tend to favor one JPA provider over the others. Add in licensing concerns and these types of specific JPA benchmarks can be messy.

    For these and other reasons, IBM generally relies on industry standard benchmarks. SpecJEnterprise, for example, takes several aspects of the application server into account but with a focus on the persistence framework. It’s been estimated that 75-80% of the SpecJEnterprise benchmark depends on the persistence layer (that is, JPA provider). The SpecJEnterprise 1Q2010 comparison clearly shows WebSphere’s leadership in this space, with similar results posed for 2Q2010 and later.

    IBM constantly compares the WebSphere Application Server JPA solution against others by primitive operations (create, retrieve, update, delete), by running running industry benchmarks, and by other methods. Many variations are measured to ensure that the WebSphere JPA solution continues to lead in performance, as well as maximize the experience and overall benefit of WebSphere Application Server.


The bottom line is that sticking with the WebSphere JPA solution rather than moving to Hibernate JPA (or any other JPA provider) makes business sense, development sense, and just common sense overall. Ease of use, lower cost, better performance, and a seamless experience not only maximizes the benefits you receive from WebSphere Application Server, but also helps to maximize the results of your development efforts.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

Zone=WebSphere, Java technology
ArticleTitle=Comment lines: Really, why Hibernate?