Check for a behavior change in JPA cascade strategy

This rule flags JPA projects that define JPA entities with relationships using a cascade strategy of PERSIST, MERGE, or ALL to make you aware of a default behavior change in the JPA 2.0 implementation in WebSphere Application Server V8.5 and Liberty. Prior to Version 8.5, when cascading a persist, the database was checked to see if the entity already exists. The new default behavior is to not check first, and to throw an "Entity key already exists" persistence exception if the entity is already in the database. The benefit of the behavior change is to improve performance by avoiding extra trips to the database.

This behavior change is not expected to affect most applications. In order to take advantage of the new behavior, you can first try the application in the Version 8.5 environment before making code changes or reverting to previous behavior.

If you do experience problems or if you know your application is written to expect the persist operation to first look in the database for new entities and does not handle the new possible persistence exception, you can revert to the previous behavior by setting the openjpa.Compatibility property in the persistence.xml:

<persistence-unit name="name" transaction-type="JTA">
...
<properties>
<property name="openjpa.Compatibility" value="checkDatabaseForCascadePersistToDetachedEntity=true"/>
</properties>
</persistence-unit>

The property can also be set as a server JVM system property if you do not want to change the application.

There is a Java rule and an XML rule associated with this potential application issue to help raise your awareness. Only one result will be flagged per project even if cascade persist is defined multiple places. This gives you the opportunity to evaluate your whole application for this issue.

In particular, you should evaluate calls to the EntityManager operations persist and merge to determine if that code will handle the behavior change properly. After you evaluate your application, you can either turn this rule off in your analysis configuration or ignore the results generated.

The Java rule will flag any of the following cascade strategies defined in a relationship annotation:

For example, the cascade types will be flagged in relationship annotations such as @OneToOne.

@Entity
public class Foo {
private Bar bar;

@OneToOne(cascade = {CascadeType.PERSIST, CascadeType.MERGE})
public Bar getBar() {
return bar;
}
}

The XML rule will flag any of the following cascade strategies defined for an entity in an orm.xml file:

<entity class="com.ibm.entities.Foo" access="FIELD">
<attributes>
<one-to-one name="bar">
<cascade><cascade-persist/><cascade-merge/></cascade>
</one-to-one>
</attributes>
</entity>

If you see any of these items flagged, you should evaluate the code that is calling merge or persist on an entity using a cascade style of persist or merge. If the application code expects that the database will be checked first before inserting a new entity, the application could experience a behavior change.

If you add the openjpa.Compatibility property to persistence.xml, run your analysis again to make sure you do not have new results on the related Check for a behavior change in JPA MetaModel code generation concerning ListAttribute rule.

For more information,