Configure JPA to work in the environment

You have developed the applications to work with Java Persistence API (JPA) and now configure the JPA applications to work in the environment.

Specify options for the database as a part of configuring JPA applications. The application server manages access to data sources. We can configure the data sources, connection pooling, and Java Transaction API (JTA) service in the console. If we have a specific data source for the application, configure the data source before you install your JPA application.

1. Configure the data sources through the console. See the topic, Configuring a JDBC provider and data source.

2. Specify the JNDI names for the <jta-data-source> and <non-jta-data-source> elements. For example to use JNDI lookup:

   <jta-data-source>jdbc/myJTADataSource</jta-data-source>
   <non-jta-data-source>jdbc/myNonJTADataSource</non-jta-data-source>

   If we use the component name space method (for example, java:comp/env) for data source retrieval, ensure that the application defines these resource references so that we can use these JNDI names to access the data source. This component name space configuration provides more flexibility if you must alter the configuration for the data source. Otherwise, the standard, direct JNDI is used as the data source name. For more information about using the JNDI interface, see the topic, Develop applications that use JNDI. For example, the persistence.xml file would have an entry like the following:

   <jta-data-source>java:comp/env/jdbc/DataSourceJNDI</jta-data-source>

   OR

   <jta-data-source>jdbc/DataSourceJNDI</jta-data-source>

3. Configure persistence provider support in the application server.

   1. Configure the JPA default persistence provider.

   2. Optional: Use third-party persistence providers.

What to do next

For more information about the commands, classes or other OpenJPA information, refer to the Apache OpenJPA User Guide.

Subtopics

• (iseries)(dist)(zos)(V8502) Configure heterogeneous SQL statement batching for JPA applications
  Heterogeneous SQL statement batching is an improvement over the org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager. This functionality can improve the performance of the JPA application because it allows multiple different SQL statements to be sent to the database in a single batch. For example, if we have a transaction that updates one Entity and also inserts another Entity, when you use the BatchingConstraintUpdateManager function, two different batches are sent to the database: one for the update and another for the insert. In the same scenario, if you use the HeteroConstraintUpdateManager function, only one batch, which contains both operations, is sent to the database.

• Configure a JDBC provider and data source
  For access to relational databases, applications use the JDBC drivers and data sources configured for the application server.

• Configure the default JTA and non-JTA data source JNDI names
  The Java Transaction API (JTA) and non-JTA data sources to be used for an application can be specified through the <jta-data-source> and <non-jta-data-source> elements of the persistence.xml file within an EJB module.

• Associate persistence providers and data sources
  Java Persistence API (JPA) applications specify the underlying data source used by the persistence provider to access the database.

• Configure persistence provider support in the application server
  Persistence providers are implementations of the Java Persistence API (JPA) specification and can be deployed in the Java EE compliant application server that supports JPA persistence.

• Configure the WSJPA FastPath for improved performance
  The Java Persistence API (JPA) is a very flexible specification that provides guidelines on how implementors are to translate relational data to Java object form. Due to the flexible nature of this API, a large amount of work is completed at runtime by the API provider to determine how to correctly load relational data into object form. This flexibility results in a runtime that, under certain circumstances, has to continually run redundant code to ensure that data is loaded properly. By giving up some of this flexibility, the WSJPA FastPath optimization attempts to skip much of this redundant code and generates highly optimized code that interacts directly with the JDBC layer.

• Task overview: IBM Optim pureQuery Runtime
  IBM Optim pureQuery Runtime provides Java Persistence API (JPA) with an alternative way to access a database. PureQuery supports static Structured Query Language (SQL).

Related tasks

Mapping persistent properties to XML columns for JPA

Associate persistence providers and data sources

Configure a JDBC provider and data source

Task overview: IBM Optim pureQuery Runtime

Configure pureQuery to use multiple DB2 package collections

Configure JDBC providers to use pureQuery to access DB2

Configure JDBC providers to use pureQuery to access Informix

Configure data source JDBC providers to use pureQuery in a Java SE environment

Develop applications that use JNDI

(V8502) Configure heterogeneous SQL statement batching for JPA applications

Criteria API

Related information:

Apache OpenJPA User Guide: JPA
Apache OpenJPA User Guide: JPA Criteria
Apache OpenJPA User Guide
Dynamic, typesafe queries in JPA 2.0

IBM System i: PTF Cover Letters

IBM Support: Fix Central for DB2 UDB for iSeries V6R1