Web programming

Units WEB1P and WEB2P

Java Persistence API (JPA)

Background

It is very common for web applications to use a database to store long-term (persistent) data.

In a well-structured application, all the code to handle the database is kept together in what we usually call the persistence layer. In the past, a typical application has contained many lines of code that had to be written to perform functions such as inserting data into the database, updating data, and finding data that meets certain conditions. Since the data, when held in the program, normally consisted of objects, much of the code that was required was about converting tablular data fetched from a database into objects in the program (and vice versa). This was often very laborious to code and time-consuming to test, despite (in many cases) having a well-known common structure.

The Java Persistence API (JPA) solves many of these problems. Instead of writing lots of low-level JDBC code, JPA allows the programmer to specify any number of classes as being "entity classes". Objects of these classes can then be persisted to and from a database without much extra code. The only overhead is the addition of a number of annotations to the class declarations. In many cases, these annotations can be produced automatically by tools (e.g. NetBeans).

See my notes on Hibernate for a bit more on the history of JPA.

What does a JPA application typically consist of?

A JPA application typically has (in the Persistence layer of its Model component):

If you are running JPA in a container (such as Glassfish), the container will automatically inject data access objects for you (when tagged with the @EJB annotation), and inject an entity manager wherever tagged with @PersistenceContext. (The container will create an appropriate entity manager factory automatically, using the information in the persistence unit.)

Typically to store some data in a database, your application would perform the following steps:

  1. Create a new object and populate its properties (e.g. using data received from the user interface)
  2. Obtain an appropriate data access object and ask that to store the object
  3. The DAO would obtain an entity manager and use its functionality to mark the object as persistent
  4. The entity manager would interact with the database to store the object in an appropriate place and at an appropriate time

Typically, to fetch some objects from a database, your application would perform the following steps:

  1. Obtain an appropriate data access object and ask it to fetch the required data.
  2. The DAO would obtain an entity manager and use its functionality to fetch one or more objects from the database
  3. Your application can then use the fetched object(s) as it wishes

Note that once an object is "managed" by an entity manager, if its value changes then updates will be automatically stored in the database. It is never necessary to tell the entity manager that an object has changed - the entity manager will work that out for itself.

What do I need to know about JPA?

The following is a (non-exhaustive) list of the JPA concepts you need to know about:

Entity classes

Entity relationships

Managing persistent objects

Related issues

Configuration

Note that JPA is very much tied up with EJBs when used in a container-managed environment.

Problem solving advice

Reading

 

Last updated by Prof Jim Briggs of the School of Computing at the University of Portsmouth

  
The web programming units include some material that was formerly part of the WPRMP, WECPP, WPSSM and WEMAM units.