Focusing on open APIs for enterprise applications

Open Web Magazine

Subscribe to Open Web Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Open Web Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Open Web Authors: Jnan Dash, Jayaram Krishnaswamy, Bob Gourley, Kevin Benedict, Pat Romanski

Related Topics: Java EE Journal, Apache Web Server Journal, Java Developer Magazine, Open Web Magazine

J2EE Journal: Article

Java Feature — Using the Java Persistence API (JPA) with Spring 2.0

How to use JPA in new or existing Spring applications to achieve standardized persistence

Using Spring, the transaction can be started and committed (or rolled back) at method entry and exit. All that needs to be done to achieve this is to declaratively state that the automatic transaction demarcation should happen. In Spring 2.0 the easiest way to do this is by annotating the bean class or method with the @Transactional annotation, although it's also possible to use XML metadata that doesn't require annotating Java code. The type of transaction that's started depends on the type of transaction manager that's configured in the Spring application context; knowledge of the underlying transaction infrastructure is completely abstracted from the Java code.

An example of a Spring bean that's transactional and uses an entity manager to perform JPA operations is the BookInventorySystem class shown below.

package org.bookguru;

import javax.persistence.*;
import org.springframework.transaction.annotation.Transactional;

@Transactional
public class BookInventorySystem {

    @PersistenceContext(unitName="BIS")
    EntityManager em;

    public void addBook(int isbn, String title, String author, Genre genre) {
       Book book = new Book(isbn, title, author, genre);
       em.persist(book);
    }
}

This class looks fairly ordinary except that the presence of two additional annotations, @Transactional and @PersistenceContext, provides us with a great deal more functionality. The @Transactional annotation causes all the methods in the class to get an automatic transaction, so a transaction will be provided whenever a caller invokes the addBook() method. We could just as easily have annotated the method directly to get this behavior, but the likelihood of adding more methods that also need a transaction is quite high, so the class is the best place for it.

The em field will get injected with an instance of EntityManager. The entity manager injected will be configured according to the named persistence unit referred to in the unitName attribute of the @PersistenceContext annotation. Named persistence units are defined and configured in the JPA persistence.xml configuration file and in the Spring application context as part of the entity manager factory bean (see Configuring the Application Context later in this article).

Despite the sparseness of the operations (we could fill it in with more operations and queries, but it's sufficient for purposes of illustration), we have a functional system, and we can now turn to the configuration.

Configuring persistence.xml
The standard JPA configuration file is an XML file called persistence.xml, and it's placed in the META-INF directory of the jar archive or on the classpath. When using JPA in most runtime environments, this file will contain most of the runtime configuration information (except O-R mapping). However, when using JPA in Spring, this file contains only the definition of the persistence unit and sometimes a list of the entity classes (if not running in a server deployment environment). An example of a persistence.xml file for us is shown below.

<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="BIS" transaction-type="RESOURCE_LOCAL">
       <class>org.bookguru.Book</class>
    </persistence-unit>
</persistence>

The type of transaction also depends on the deployment environment. In this example, we're running in a simple Java SE virtual machine (VM) and don't have access to a JTA transaction manager, so we set the transaction type to RESOURCE_LOCAL.

Configuring the Application Context
Every Spring application must eventually construct an application context - a set of bean definitions that specify the dependencies that a bean has on others. A Spring "bean" is a component in the application; it's configured by Spring and eligible to benefit from the services Spring provides. The application context determines how the beans fit together at runtime and provides the flexibility to rewire parts of an application in different ways without having to change the application Java code.

Configuring the Entity Manager Factory Bean
As part of its support for JPA, Spring 2.0 provides several JPA-related classes intended to be used as Spring beans. The most important of these is the entity manager factory bean, which makes a JPA entity manager factory available to the application. This bean has dependencies that determine the parameters of JPA execution in Spring, and although many of these settings can be defined in the JPA persistence.xml file, the Spring application context can provide additional flexibility and configur-ability. It also provides a configuration style and experience that's consistent with what Spring users are accustomed to.

Configuring the entity manager factory bean involves configuring three main dependencies: the persistence unit name, the data source, and the load time weaver. This is done as follows:

    <bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
       <property name="persistenceUnitName" value="BIS"/>
       <property name="dataSource" ref="dataSource"/>
       <property name="loadTimeWeaver"
class="org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver"/>
       <property name="jpaVendorAdapter" ref="vendorAdapter"/>
    </bean>

The type of component created by this bean definition is EntityManagerFactory, which is the starting point for JPA usage.


More Stories By Mike Keith

Mike Keith has more than 15 years of teaching, research and practical experience in object-oriented and distributed systems, specializing in object persistence. He was the co-specification lead for EJB 3.0 (JSR 220), a member of the Java EE 5 expert group (JSR 244) and co-authored the premier JPA reference book Pro EJB 3: Java Persistence API. Mike is currently a persistence architect for Oracle and a popular speaker at numerous conferences and events around the world.

More Stories By Rod Johnson

Rod Johnson is the senior vice president of the Application Platform Division at VMware with more than 12 years of technology and management experience. Founder of the Spring Framework, he continues to guide the direction of Spring and is a member of the Java Community Process Executive Committee.

Comments (2)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.