When does JPA's EntityManager give Performance Benefits over plain JDBC?

Question

I am working on a database application for a client. The old application code is quite inconsistent in how it accesses the database; in some methods it's using Hibernate objects, in others it creates JDBC connections directly and uses pure SQL, in some it creates Hibernate connections and uses those to get the JDBC connection. In any case, we're going to overhaul a lot of code to make it consistent. Our client has heard of JPA, and asked us to use it, because the client believes it will come with a performance benefit.

The problem is, my understanding of the performance benefits from JPA is that the big benefit comes from JPA's EntityManager, because it allows you to persist objects in-memory between database calls. However, the application we're working on won't be the only application accessing the database, and will run in multiple instances at multiple locations. In addition, EntityManagers aren't thread-safe so we wouldn't even be able to see changed data in a different part of the same application. As such, it looks like we would need to get a new EntityManager from the EntityManagerFactory in each method, and close it when the method is complete. Thus, we wouldn't really be able to persist objects in-memory very long, because other applications would need the data we change & change the data we need.

The current code is such a mess that moving to JPA would give major benefits in maintainability and consistency anyways. However, if it won't provide performance benefits, we should let the client know as soon as possible so they're not disappointed. Are there other ways that JPA provides performance benefits besides the obvious one related to Persistance Contexts?

I've checked other questions on StackOverflow, but the ones I've found talk about changes in large batches (example here). Our client wants the changes made by one application to be visible to other applications as soon as possible, so our application will make several small changes, rather than occasional batch changes.

Thank you.

Answer 1

JPA is a standard for OR/M and There are many reasons to use an ORM framework or persistence product, and many reasons to use JPA in particular.

Reasons for ORM

• Eliminates all of the 'hand' mapping in Java from a SQL ResultSet to a Java POJO greatly reducing the amount of mapping work.
• Reduces the amount of work required to the persistence code base with a domain data model and/or relational data model change.
• Leverages large persistence library to avoid developing solutions to problems that others have already solved.
• Avoids low level JDBC and SQL code.
• Leverages object oriented programming and object model usage.
• Provides database and schema independence.
• Most ORM products are free and open source.
• Many enterprise corporations provide support and services for ORM products.
• Provides high end performance features such as caching and sophisticated database and query optimizations.

Reasons for JPA

• It is a standard and part of EJB3 and Java EE.

• Many free and open source products with enterprise level support.

• Portability across application servers and persistence products (avoids vendor lock-in). A usable and functional specification.

• Supports both Java EE and Java SE.

ORM can be a hot topic for some people, and there are many ORM camps. There are those that endorse a particular standard or product. There are those that don't believe in ORM or even objects in general and prefer JDBC. There are those that still believe that object databases are the way to go. Personally I would recommend you use whatever technology you are most comfortable with, but if you have never used ORM or JPA, perhaps give it a try and see if you like it. The below list provides several discussions on why or why not to use JPA and ORM. (From wikibooks)

Here is some useful linkes: JPA or JDBC, how are they different? , Java Persistence/Why use JPA or ORM?, JPA is great but damned slow

Answer 2

JPA will not necessarily give you any performance advantage over plain JDBC. It might have big imapcts on your system. It all depends on how you use it.

It sounds like you are using Hibernate already. JPA itself is a specification, which is implemented by a number of vendors or providers. Hibernate is one of them (and is the JPA2 provider that I use at work).

Creating an EntityManagerFactory can take some time. Creating an EntityManger, on the other hand, is fast and lightweight.

If you are experiencing poor performance, you might try profiling the code to see where the performance issues lie.

Moving to a single access layer sounds like a good idea to me, though, and it does improve maintainability and consistency.