2. OpenJPA 2.2.0
Prev | Appendix 3. Migration Considerations | Next

## 2. OpenJPA 2.2.0

### 2.1. Incompatibilities

The following sections indicate changes that are incompatible between OpenJPA 2.1.x releases and the 2.2.0 release.

#### 2.1.1. allocationSize Property of Sequence Generator

In previous releases, specifying the `allocationSize` property of sequence generator affected only sequence definition in the database. During schema creation, the `INCREMENT BY` clause of `CREATE SEQUENCE` statement always had a value of 1 and on DB2, Oracle and PostgreSQL databases a `CACHE` clause was added with the value of `allocationSize` property. Such a statement caused sequence values being cached in the database. Starting with OpenJPA 2.2.0, sequence values are cached in the jvm memory and the `allocationSize` property determines size of that cache. The `CACHE` clause is no longer used, instead the `INCREMENT BY` clause gets its value equal to the `allocationSize` property. Such a strategy reduces the number of database roundtrips required for retrieving sequence values considerably.

In order for the existing applications to work with OpenJPA 2.2.0, you have to manually recreate or redefine sequences, specifying the correct `INCREMENT BY` value and, possibly, correct initial sequence value. Note that the default value of the `allocationSize` property is 50 and that value is used if the property is not specified.

The requirement for sequence modification applies to all databases that support sequences, regardless of the `CACHE` clause being supported. The only exception is Firebird database - since with this database the increment step is determined during sequence value fetch, no migration activity is needed.

To maintain the old behavior of sequence generator in OpenJPA 2.2.0, you can:

- Set the `allocationSize` property value to 1.

- Additionally, if the `CACHE` clause has to be emitted in sequence definition, this can be accomplished by overriding the `DBDictionary.getCreateSequenceSQL` method.

#### 2.1.2. MetaModel Attributes for Arrays

In previous releases OpenJPA's MetaModel implementation generated a ListAttribute for every array. This behavior is correct if the array is annotated as a PersistentCollection, but not correct for un-annotated arrays (e.g. byte[], char[]). In OpenJPA 2.2.0 this behavior was corrected so that arrays which are not stored as PersistentCollections will use a SingularAttribute instead of a ListAttribute.

If your application uses the MetaModel API and your entities contain arrays of any of the following types: byte[], Byte[], char[], Character[] and do not use the @PersistentCollection annotation with those fields you will need to update your application to use OpenJPA 2.2.0.

In order for the existing applications to work with OpenJPA you may:

- Regenerate the canonical metamodel classes

- Set the Compatibility property `UseListAttributeForArrays` to `true` in persistence.xml

       <property name="openjpa.Compatibility" value="UseListAttributeForArrays=true"/>

#### 2.1.3. supportsSetClob Property.

In OpenJPA 2.2.0, code was added to allow the setting of CLOB or XML data larger than 4000 bytes. This functionality was eventually back ported to previous releases, and enabled by the `supportsSetClob` property on the OracleDictionary. Setting this property has no effect in 2.2.0 and later releases and any occurrence of it should be removed.

#### 2.1.4. useNativeSequenceCache Property.

In OpenJPA 2.2.0, code was added which changed the way sequences were generated, please see Section 2.1.1, “ allocationSize Property of Sequence Generator ” for details. This functionality was eventually back ported to previous releases, and enabled by the `useNativeSequenceCache` property on the DBDictionary. Setting this property has no effect in 2.2.0 and later releases and any occurrence of it should be removed. If previous behavior is desired (i.e. `useNativeSequenceCache=true`), please see the details described in section Section 2.1.1, “ allocationSize Property of Sequence Generator ”.

#### 2.1.5. Cascade persist behavior

In previous releases, OpenJPA would check the database for the existence of the related Entity before persisting the relationship to that Entity. This resulted in an extra Select being sent to the database. In 2.2.0, code was added so that when cascading a persist to a related Entity without persistence state, the persist (insert) will happen without first checking the database. This may result in an EntityExistsException if the related Entity already exists in the database. To revert this behavior to the previous release, set the value of the `openjpa.Compatibility` property `CheckDatabaseForCascadePersistToDetachedEntity` to `true`.

#### 2.1.6. Life Cycle Event Manager Callback Behavior

Life cycle event manager is used to manage entity's life cycle event callback. In previous releases, Life cycle event manager is scoped to EntityManagerFactory. This means listeners registered to an individual EntityManager may get life cycle event callbacks for entity that it does not manage.

From 2.2.1 release, the default callback behavior of the life cycle event manager is changed to scope to each EntityManager. To revert this behavior to the previous release, set the value of the `openjpa.Compatibility` property `SingletonLifecycleEventManager` to `true`.

#### 2.1.7. shared-cache-mode Property

In the previous release, when the shared-cache-mode is enabled and the DataCache property is not set or set to false, there will be no data caching.

From 2.2.2 release, the caching will be turned on if the shared-cache-mode is enabled. Please see the details described in section Section 1.1.2, “ Integration with JPA standard shared cache mode ”.

Prev | Up | Next
Appendix 3. Migration Considerations | Home | 3. OpenJPA 2.3.0