Beta Draft: 2012-12-13
This section contains the following tasks:
Task 2: Change the Provider and Persistence Unit Properties in persistence.xml
Task 3: Convert Query Hint Names Used in Named and Dynamic Queries
Task 4: Convert or Fix Nonstandard Mappings Available in OpenJPA
EclipseLink 2.4 or later.
Download EclipseLink from http://www.eclipse.org/eclipselink/downloads/
.
Update the following properties in the persistence.xml file, as needed:
Set the JPA persistence provider to org.eclipse.persistence.jpa.PersistenceProvider
, to ensure that EclipseLink JPA is used as the provider, in case multiple providers exist in the target container.
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
When using OpenJPA with Java SE, the provider resolver may continue to use OpenJPA, instead of the specified provider, if OpenJPA is encountered first on the classpath. If this happens, remove OpenJPA from the classpath of your application. |
Persistence unit properties are a standard mechanism for providing vendor-specific configuration. The following sections list OpenJPA persistence unit properties that must be replaced when migrating from OpenJPA to EclipseLink:
Not all OpenJPA persistence unit properties have exact equivalents in EclipseLink, so you may have to consult the OpenJPA documenation and the EclipseLink documentation to determine a conversion strategy. For complete reference documentation on the EclipseLink extensions to standard JPA persistence properties, see "Persistence Property Extensions Reference" in Java Persistence API (JPA) Extensions Reference for EclipseLink. For complete EclipseLink Javadoc, see Java API Reference for EclipseLink.
JDBC properties are used to configure internal connection pooling typically used in Java SE or in containers where data sources are not available. Table 7-1, "JDBC Persistence Unit Properties" compares OpenJPA JDBC properties to the corresponding or related EclipseLink properties.
For information about the EclipseLink JDBC persistence properties, see "JDBC Configuration Options" in Java Persistence API (JPA) Extensions Reference for EclipseLink.
In JPA 2.0 several persistence unit properties for JDBC configuration were standardized. Therefore, beginning in EclipseLink 11.1.1.2, the equivalent EclipseLink properties were deprecated and replaced by the JPA 2.x standard ones. Both are shown in the EclipseLink JPA Equivalent column of Table 7-1. |
Table 7-1 JDBC Persistence Unit Properties
OpenJPA Property | Description | EclipseLink JPA Equivalent |
---|---|---|
|
The full class name of either the JDBC |
EclipseLink 11.1.1.0 - 11.1.1.1: EclipseLink 11.1.1.2 +: |
|
The password for the user, specified in the |
EclipseLink 11.1.1.0 - 11.1.1.1: EclipseLink 11.1.1.2 +: |
|
The JDBC URL for the database. |
EclipseLink 11.1.1.0 - 11.1.1.1: EclipseLink 11.1.1.2 +: |
|
The user name to use when connecting to the database. |
EclipseLink 11.1.1.0 - 11.1.1.1: EclipseLink 11.1.1.2 +: |
Other JDBC issues to consider include:
The OpenJPA properties containing "2
," for example openjpa.Connection2DriverName
, are for the unmanaged connection pool. EclipseLink uses the same information for both managed and unmanaged connections. If separate login information is required for unmanaged connections, it must be configured in code.
Connection properties and custom connectors equivalent to OpenJPA connection factories are supported through DatabaseLogin
, DatabasePlatform
, and custom Connector
s. These are generally not required with containers but can be configured using a SessionCustomizer
, if needed.
EclipseLink uses its own shared entity caching feature instead of a data cache requiring a 3rd party implementation. Table 7-2, "Caching Persistence Unit Properties" compares OpenJPA caching properties to the corresponding or related EclipseLink properties.
Table 7-2 Caching Persistence Unit Properties
OpenJPA Property | Description | EclipseLink JPA Equivalent |
---|---|---|
|
The data cache implementation to use for data caching. |
Not Required |
|
The data cache manager to use for managing the system data caches. |
Not Required |
|
The duration that data in the data cache is valid. |
EclipseLink provides expiration and invalidation per entity cache, based on the time since it was read or on the time of day. Configure these by using a |
|
The query cache implementation to use for caching of queries loaded from the data store. |
EclipseLink supports query result caching through the query hint |
|
The map to use for caching data of compiled queries |
EclipseLink automatically caches generated SQL strings and prepared statements. The size of these caches is configurable. |
Table 7-3, "Diagnostic Properties" compares the OpenJPA logging property to the corresponding EclipseLink property.
Table 7-4, "Other Properties" compares miscellaneous other OpenJPA properties to the corresponding or related EclipseLink properties.
Table 7-4 Other Properties
OpenJPA Property | Description | EclipseLink JPA Equivalent |
---|---|---|
|
When to clear instance state: on entering a datastore transaction or on entering any transaction. |
|
|
Events that cause managed instances to be detached. |
Not applicable. Entities can be used with other entity mangers as detached at any time. However, they are always considered managed relative to the reading entity manger, as long as it is open and the entity has not been serialized. |
|
The broker factory to use. |
The EclipseLink Direct configuration in XML is not supported. Custom server session types are supported through API only. |
|
The broker type to use at runtime. |
The EclipseLink The |
|
The class resolver to use to resolve class names. |
Specify the EclipseLink |
|
Options to ensure compatibility with previous OpenJPA releases. |
Not required when migrating. |
|
Determines which fields are part of the detached graph and related options. |
Use the JPA 2.0 |
|
Whether to dynamically generate customized structs to hold persistent data. |
|
|
The number of rows to fetch at a time when scrolling through a result set. |
EclipseLink batching and joining depth and size is configurable on queries instead of globally. |
|
Fetch groups to be loaded when retrieving objects from the datastore. |
EclipseLink's default fetch group is determined by the |
|
Determines which fields are part of the detached graph and related options. |
EclipseLink determines detached state based on usage along with lazy loading configurations and dynamic fetch groups. Lazy relationships can always be retrieved until the entity is truly detached through serialization or copying. |
|
Whether to flush changes made in the current transaction to the datastore before executing a query. |
EclipseLink relies on the standard |
|
Avoid tracking changes |
EclipseLink provides similar support using |
|
Identifier for current configuration, for example, persistence unit name. |
Equivalent to |
|
Whether to consider changes to persistent objects made in the current transaction when evaluating queries. |
|
|
The lock manager to use to use for acquiring locks on persistent instances during transactions. |
|
|
Time to wait for an object lock before throwing an exception |
|
|
The managed runtime implementation to use to obtain a reference to the transaction manager in an enterprise environment. |
This is generally supported in EclipseLink through the |
|
Name of the object-to-datastore mapping to use. |
|
|
The maximum depth of relations to traverse when eager fetching. |
|
|
The metadata factory to use to store and retrieve metadata for persistent classes. |
|
|
Whether persistent instances and components other than the entity manager factory are accessed by multiple threads simultaneously. |
|
|
Selects between optimistic and pessimistic (datastore) transactional modes. |
|
|
The orphaned key action to invoke when OpenJPA discovers an orphaned datastore key. |
|
|
Whether the runtime allows data to be read outside of a transaction. |
|
|
Whether persistent objects can be modified and whether persistence operations can be performed outside a transaction. |
|
|
The proxy manager to use for proxying mutable second class objects. |
|
|
The remote commit provider implementation to use for distributed event notification. |
|
|
Whether to restore managed fields to their pretransaction values when rolled back. |
|
|
Whether to defer registration instead of throwing an exception when a persistent class cannot be processed |
|
|
The savepoint manager to use for managing transaction savepoints. |
|
|
The kernel sequence implementation to use for the system sequence. |
|
|
The default transaction mode to use. |
|
|
The default level to use to lock objects changed during a non-optimistic transaction. |
JPA applications can include query hints, which define provider-specific behavior. These hints can be specified in annotations, ORM XML files, or application code. The query hint names are strings and therefore do not typically force compile time dependencies on the provider. However, the values
for these hints may introduce dependencies.
Table 7-5, "Query Hints" compares OpenJPA query hint to the corresponding or related EclipseLink features.
Table 7-5 Query Hints
OpenJPA Property | Description | EclipseLink JPA Equivalent |
---|---|---|
|
Specifies an Oracle-specific query hint to be generated. |
Use |
|
Values= |
Use JPA 2.0 |
|
Sets the size for a query result set. |
Use |
|
Specifies the isolation level using the |
|
|
The maximum depth of relations to traverse when eager fetching. |
Specify |
|
The number of rows to fetch at once when scrolling through a result set. |
Use |
|
Time to wait to acquire a lock. |
Use |
|
Determines how to eager-fetch a field. |
EclipseLink fetch group loading is done based on the attributes specified for the fetch group. In the case of the default |
|
Determines how to eager-fetch subclass data. |
Fetch group attributes can be assigned to any mapped attribute in the target entity or its mapped parent classes. |
Using a JPA mapping tool such as Oracle JDeveloper or Oracle Enterprise Pack for Eclipse (OEPE) makes mapping entities easier and less error-prone. Such tools provide validation and configuration assistance to address many common mapping errors. |
The following are some mapping scenarios you might encounter when migrating from OpenJPA to EclipseLink.
When defining relationship mappings involving foreign keys (@OneToOne
and @ManyToOne
), JPA supports the specification of non-default column names using @JoinColumn
and @JoinColumns
. OpenJPA allows the specification of @Column
. Since this has no defined meaning in JPA, EclipseLink throws a validation exception to assist customers in identifying this incorrect mapping configuration.
Solution
Convert all @OneToOne
and @ManyToOne
mappings that have an @Column
configuration to use @JoinColumn
. If the target class of the relationship has a composite identifier (primary key) you must use @JoinColumns
.
If the relationship defined by the @JoinColumn
(s) involves columns which are also mapped as identifiers (primary key columns), make sure they are mapped with @Id
and that the duplicate mappings are properly mapped and managed in the entity class.
The JPA specification does not define whether mappings (@Basic
, @OneToOne
, @ManyToOne
, @OneToMany
, @ManyToMany
, etc.) can be specified to be transient. While OpenJPA allows this, EclipseLink correctly throws an exception. Transient configuration on an attribute is intended to prevent default mappings from being applied when calculating the mappings for an entity. With default mappings, unmapped attributes are assumed to be mapped according to the specification. @Transient
prevents these assumptions, which may not be the desired behavior.
Solution
Determine which configuration you want. If you want mapping, remove @Transient
. If the intention was to avoid the default mapping, then either remove or comment out the mapping configuration.
OpenJPA offers some extended functionality that goes beyond the JPA specification. The following sections describe these features and how you can migrate to the corresponding functionality in EclipseLink.
After completing the conversion to EclipseLink JPA it is also very important to harness the additional features available. The most commonly used features include:
Caching - Make sure you understand and optimize your cache configuration to work with your locking policies and the volatility of your underlying database tables:
Shared (L2) versus Isolated (EntityManager/TX)
Shared type, size, and expiration/invalidation
Cache coordination (where applicable)
Query Optimization - Minimize the amount of data loaded and cached for greater performance and optimal cache usage:
Batch and Joined (multi-level) for graph retrieval
Cache usage and refreshing
Data projections for data loading on searches where full entities are not required
Paged data/entity loading
Fetch Groups
Weaving - Ensure weaving is enabled for change tracking, lazy loading, and fetch groups capabilities .