Use this information to find various known problems with JPA applications.
Under certain conditions, a message similar to the following might be logged:
Unable to execute {0} on a WebSphere managed transaction. WebSphere does not support direct manipulation of managed transactions.
This error is probably caused by a data source that is not configured correctly as <non-jta-data-source>. See the information center topic on how to configure a data source to be used as a <non-jta-data-source>.
It is difficult to diagnose these situations. Sometimes you can trace the problem back to a lack of OpenJPA enhancement of entity classes. Examples of these situations might be detecting when entities are not "persistence capable". Look for a message similar to the following in the log:
This configuration disallows runtime optimization, but the following listed types were not enhanced at build time or at class load time with a javaagent: "{0}".
This message indicates that the expected runtime enhancement did not take place on the listed entity types. In most cases, this is just a build time failure and the PCEnhancer needs to be run on the listed classes. It can also indicate a more involved problem, especially if you are expecting the container classloader transform to do the entity enhancement.
The following is an exception from DB2® in the log org.apache.openjpa.persistence.PersistenceException:
[ibm][db2][jcc][10120][10898] Invalid operation: result set is closed can be a WebSphere® Application Server configuration problem.
Per the JPA specification, EntityManagers are meant to be used by a single thread. You might receive an exception message that is similar to the following (in this context, brokers and EntityManagers are essentially the same thing):
Multiple concurrent threads attempted to access a single broker. By default brokers are not thread safe; if you require and/or intend a broker to be accessed by more than one thread, set the openjpa.Multithreaded property to true to override the default behavior.
There are some ways to address this issue:@Entity public class VersionedTimestampEntity { @Id private int id; @Version private java.sql.Timestamp version; .... }The provider updates the versioned property to a new value when an entity is written to the database. During an entity merge operation, the persistence provider examines this versioned property to determine if the entity that is being merged is a stale copy of the entity. If the operation failed due to the stale versioning condition, an OptimisticLockException will be thrown. The versioned property can be one of these types:
The JPA providers included with WebSphere Application Server use a constraint update manager to determine the order of SQL requests to the database based on each entity's configuration. This update manager may rearrange the order of SQL requests to the database. This alleviates an application from knowing the order of entity manager operations required to perform its business logic and optimizes database performance using underlying batching support.
Since the JPA provider does not assume that there are implied database constraints for relationships between entities, if there are constraints in the database (for example, a foreign key constraint) the JPA provider may not issue SQL statements in the desired order. Under these conditions, the following or similar exception may be observed:
com.ibm.db2.jcc.b.SqlException: DB2 SQL error: SQLCODE: -530, SQLSTATE: 23503, SQLERRMC: xxxxxx
<property name="openjpa.jdbc.SchemaFactory" value="native(ForeignKeys=true)" />
public class Person { @ManyToOne @ForeignKey private Address address; .... }
<property name="openjpa.jdbc.UpdateManager" value="operation-order" />
With this configuration option present, the JPA provider will execute the SQL statements in the same order as the entity operations were requested. The application must be aware of any interdependencies between entities.
The MappingTool ANT task provided by OpenJPA uses a temporary classloader to load the JDBC driver classes. This temporary classloader may have trouble loading some JDBC drivers such as DB2.
When you run the MappingTool ANT task, you could see something similar to the following error:
[mappingtool] java.lang.UnsatisfiedLinkError: com/ibm/jvm/Trace.initTrace([Ljava/lang/String;[Ljava/lang/String;)V [mappingtool] at com.ibm.jvm.Trace.initializeTrace(Trace.java:94) [mappingtool] at com.ibm.jvm.Trace.<clinit>(Trace.java:59) [mappingtool] at java.lang.J9VMInternals.initializeImpl(Native Method) [mappingtool] at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) [mappingtool] at java.lang.Class.forNameImpl(Native Method) [mappingtool] at java.lang.Class.forName(Class.java:136) [mappingtool] at com.ibm.db2.jcc.a.o.n(o.java:577) [mappingtool] at com.ibm.db2.jcc.a.o.<clinit>(o.java:329)In order to use the mapping tool, you can disable the temporary classloader by adding the tmpClassLoader=false argument to the ANT task. Two example ANT scripts follow :
This example will exhibit the problem:
<taskdef name="mapping" classname="org.apache.openjpa.jdbc.ant.MappingToolTask" classpathref="jpa.cp"/> . . . <target name="map.broken"> <mapping> <!-- this will exhibit the problem --> . . . </mapping> </target>
This example will prevent the problem:
<taskdef name="mapping" classname="org.apache.openjpa.jdbc.ant.MappingToolTask" classpathref="jpa.cp"/> . . . <target name="map.fixed"> <mapping tmpClassLoader="false"> <!-- this will work --> . . . </mapping> </target>
When an application persists an inconsistent domain model and later retrieves the entities in a separate persistence context, the retrieved entities will differ depending on whether DataCache is active or not.
For example, consider bi-directional, one-to-one relationship between two entities mapped by a single foreign key column in the database. It is possible for an application to set the relation fields in the entities inconsistently. When such inconsistent values are mapped to the database, the database records become consistent only because a single foreign key column expresses the bi-directional relationships DataCache is active, however, then DataCache captures the inconsistent in-memory entity states. Therefore, when an application persists a pair of entities related in a bi-directional relation but their relation fields are set to inconsistent values and later retrieves the entities in a different persistence context, the bi-directional relationship either remains inconsistent or becomes consistent depending on whether DataCache is used or not.
When multiple fields are mapped to the same column but set to different values is another example where an inconsistent entity state is persisted but retrieved as consistent in a separate persistence context. In this case, the introduction of DataCache will also cause an entity realized in a separate persistence context to retain different and inconsistent values while without a DataCache, an entity will hold the same value for both the fields.
The OpenJPA mapping tool is unable to create ForeignKey constraints when used with Sybase Adaptive Server. As a result, the foriegn key constraints must be created manually.
<property name="openjpa.Compatibility" value="StrictIdentityValues=true"/>
If you need to set a different compatibility option, for example ReloadOnDetach=false, you must specify both options as parameters of the same property statement in the persistence.xml file. For example :
<property name="openjpa.Compatibility" value="StrictIdentityValues=true,ReloadOnDetach=false"/>
In this information ...Subtopics
| IBM Redbooks, demos, education, and more(Index) Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience. This feature requires Internet access. Most of the following links will take you to information that is not part of the formal product documentation and is provided "as is." Some of these links go to non-IBM Web sites and are provided for your convenience only and do not in any manner serve as an endorsement by IBM of those Web sites, the material thereon, or the owner thereof. |