Use third-party persistence providers

Java Persistence API (JPA) for WAS allows users to specify third-party persistence providers in their appserver environment.

Java EE applications that use JPA functions can employ third-party persistence providers other than those that are included with the appserver. Applications can also specify an Apache OpenJPA provider that is other than the version that is included with the appserver. There are two basic means to incorporate third-party providers into an application:

• Embedding the persistence provider inside an application

• Making use of shared libraries.

Depending on the requirements, we can embed a persistence provider inside an application, or place the persistence provider into a shared library.

 

• Embedding a third-party persistence provider within an application

  Sometimes an application design must rely on the implementation of a specific persistence provider. The JPA spec permits embedding of a specific JPA provider within a persistence archive. When building the application, we can assemble a specific version of a provider's implementation in the application EAR file or in a web application (WAR) file. To embed a third-party persistence provider into an application, we need to inspect the application design and all dependent prerequisites. Use the following steps to embed a persistence provider inside an application:

  1. Modify the <provider> element to specify explicitly which persistence provider to use to access the persistence entity.

  2. Build the specific version of the third-party persistence provider into the application. To manage the persistence correctly, verify that the EntityManagerFactory and the EntityManager are calling the correct provider. Many providers write startup and version information to standard output, which gets included in the SystemOut.log of the appserver. This information can be helpful to determine if a third-party provider is being used by the application.

  3. To use a third-party JPA provider that was not bundled with the appserver, configure the class loader order for the application to load the classes with the application class loader first. This is also required if the third-party JPA provider is defined in a shared library assigned to a user-defined classloader on the server. If the class loader is not configured properly, the third-party JPA provider that is included with the appserver will be loaded and used by the application.

  4. Depending on how you packaged the provider, perform one of the

     • If we packaged the provider in an EAR file, specify the third-party persistence provider binaries in the Manifest.mf classpath in those application modules that needs JPA access.

     • If the provider was bundled in a WAR file, include the necessary provider binaries in the WEB-INF/lib directory of the web application.

  5. Install the application normally.

  This configuration localizes the availability of the provider and limiting it to the application alone. While sometimes necessary, embedding persistence providers will increase the application's memory footprint accordingly.

• Use shared libraries to implement a third-party persistence provider Persistence providers accessed by applications in a global environment can be installed as a shared library for the application server. Depending on the requirements, we can share the library to the server and application. Use the following steps to implement a third-party persistence provider using shared libraries:

  1. Modify the <provider> element to specify explicitly which persistence provider to use to access the persistence entity.

  2. Define the persistence provider in a shared library. See the topic on creating shared libraries for more information.

  3. Associate the shared library with the application class loader, or associate the shared library with the server class loader if the library is accessed by many applications.

  4. Set the class loader order for the application to load the classes with the application class loader first. This is required if the third-party JPA provider is included in the application or if it is defined in a shared library. If the class loader is not configured properly, the JPA provider that is included with the appserver will be used by the application instead of the third-party JPA provider.

  When the application starts, the specified persistence provider will be resolved. From this point on, all persistence requests will be handled by this provider.

• If the shared library persistence provider is overriding an existing persistence provider that is the same type and exists in the application's classloader hierarchy (example: attempting to override the version of OpenJPA that is shipped with WebSphere), using an isolated classloader for the shared library is recommended. See the topic on creating shared libraries for more information.

 

Related tasks

Set the Java Persistence API (JPA) default persistence provider
Create shared libraries
Set class loaders of a server
Set Persistence Provider support in the appserver