Fehlerbehebung bei JPA-Anwendungen
Verwenden Sie diese Informationen, um verschiedene bekannte Probleme mit JPA-Anwendungen (Java™ Persistence API) zu finden.
Vorgehensweise
- Führen Sie die Fehlerbehebung für NoClassDefFoundError für org.apache.openjpa.*- oder com.ibm.websphere.persistence.*-Klassen durch, wenn Sie die
JAR-Datei für den JPA-Thin-Client verwenden.
In WebSphere Application Server Version 9.0 sind zwei JAR-Dateien für den JPA-Thin-Client verfügbar. com.ibm.ws.jpa-2.1.thinclient_9.0.jar enthält Schnittstellen der Spezifikation JPA 2.1 sowie EclipseLink-Klassen und Schnittstellen. com.ibm.ws.jpa-2.0.thinclient_9.0.jar enthält Schnittstellen der Spezifikation JPA 2.0 sowie WSJPA- und OpenJPA-Klassen und Schnittstellen. Vor Version 9 hatte diese JAR-Datei den Namen "com.ibm.ws.jpa_X.X.jar".
Fehler vermeiden:
Wenn Ihre Anwendung von OpenJPA- oder WSJPA-spezifischen Klassen oder Verhaltensweisen abhängig ist und Sie Ihrem Klassenpfad com.ibm.ws.jpa-2.1.thinclient_9.0.jar hinzugefügt haben, müssen Sie com.ibm.ws.jpa-2.0.thinclient_9.0.jar stattdessen in Ihrem Thin-Client-Klassenpfad verwenden.
gotcha - Führen Sie die Fehlerbehebung für NoClassDefFoundError für org.apache.openjpa.*- oder com.ibm.websphere.persistence.*-Klassen über eine Anwendung durch, die in WebSphere Application Server ausgeführt wird. In WebSphere Application Server Version 9.0 wurde der Standardpersistenzprovider für neue Profile von OpenJPA in EclipseLink geändert. Wenn Sie eine OpenJPA-Anwendung ausführen und WebSphere für die Verwendung von EclipseLink konfiguriert ist, wird ein Fehler des Typs "NoClassDefFoundError" erzeugt. Dies ist darauf zurückzuführen, dass OpenJPA-Klassen der Serverlaufzeitumgebung nicht zur Verfügung stehen, wenn sie für die Verwendung von JPA 2.1 konfiguriert sind.Anmerkung: Wenn Sie die Migrationstools von WebSphere Application Server Version 8.5.5 verwenden, um eine Migration auf WebSphere Application Server Version 9.0 durchzuführen, wird die JPA-Stufe automatisch auf 2.0 gesetzt und dort derselbe JPA-Provider wie in WebSphere Application Server Version 8.5.5 verwendet.
Zum Beheben des Problems müssen Sie Ihren Server oder Ihren Cluster erneut so konfigurieren, dass JPA 2.0 verwendet wird. Dadurch wird OpenJPA als Standardpersistenzprovider festgelegt.
- Führen Sie die Fehlerbehebung für NoClassDefFoundError: org.apache.openjpa.enhance.PersistenceCapable durch. Anwendungen,
die OpenJPA verwenden, können zur Buildzeit ausgeführte Erweiterungstools in Entitätsklassen verwenden. Durch Verwendung der OpenJPA-Erweiterung
werden der kompilierten Klasse Referenzen auf Klassen wie "org.apache.openjpa.enhance.PersistenceCapable"
hinzugefügt. In WebSphere Application Server Version 9.0 wurde der Standardpersistenzprovider für neue Profile von OpenJPA in EclipseLink geändert. Wenn Sie versuchen, eine Anwendung mit OpenJPA-Erweiterung auszuführen, und WebSphere Application Server für die Verwendung von EclipseLink konfiguriert ist, wird Fehler des Typs "NoClassDefFoundError" erzeugt. Dies ist darauf zurückzuführen, dass OpenJPA-Klassen der Serverlaufzeitumgebung nicht zur Verfügung stehen, wenn sie für die Verwendung von JPA 2.1 konfiguriert sind.Anmerkung: Wenn Sie die Migrationstools von WebSphere Application Server Version 8.5.5 verwenden, um eine Migration auf WebSphere Application Server Version 9.0 durchzuführen, wird die JPA-Stufe automatisch auf 2.0 gesetzt und dort derselbe JPA-Provider wie in WebSphere Application Server Version 8.5.5 verwendet.Um das Problem zu beheben, können Sie wie folgt vorgehen:
- Konfigurieren Sie Ihren Server oder Ihren Cluster erneut so, dass JPA 2.0 verwendet wird. Dadurch wird OpenJPA als Standardpersistenzprovider festgelegt.
- Kompilieren Sie Ihre Anwendung erneut und erweitern Sie die Entitäten mit der EclipseLink-Erweiterung und nicht mit der OpenJPA-Erweiterung.
- Prüfen Sie die Nachrichten und die zugehörigen Transaktionen.
Unter bestimmten Bedingungen kann eine Nachricht wie die folgende protokolliert werden: Unable to execute {0} on a WebSphere managed transaction. WebSphere does not support direct manipulation of managed transactions.
Dieser Fehler wird vermutlich von einer Datenquelle verursacht, die nicht ordnungsgemäß als <non-jta-data-source> konfiguriert ist. Informationen zum Konfigurieren einer Datenquelle, die Sie als <non-jta-data-source> verwenden möchten, finden Sie im Artikel "Persistenzprovider und Datenquellen zuordnen" im Information Center.
- Fehlerbehebung in Klassen, die von der Laufzeit nicht erweitert wurden.
Es ist schwierig, diese Situationen zu diagnostizieren. Manchmal kann das Problem auf das Fehlen einer OpenJPA-Erweiterung von Entitätsklassen zurückgeführt werden. Beispiele für diese Situationen sind möglicherweise zu finden, wenn Entitäten nicht persistenzfähig sind. Suchen Sie im Protokoll nach einer Nachricht wie der folgenden: In dieser Konfiguration ist die Laufzeitoptimierung nicht erlaubt, aber die folgenden aufgelisteten Typen wurden während des Build oder während der Klassenladezeit nicht mit einem Java-Agenten erweitert: "{0}".
Diese Nachricht weist darauf hin, dass die erwartete Laufzeiterweiterung für die aufgelisteten Entitätstypen nicht stattgefunden hat. In den meisten Fällen handelt es sich bei diesem Fehler lediglich um einen Buildzeitfehler, und PCEnhancer muss für die aufgelisteten Klassen ausgeführt werden. Er kann aber auch auf ein umfassenderes Problem hinweisen, inbesonders, wenn erwartet wird, dass die Entitätserweiterung bei der Umsetzung des Containerklassenladers durchgeführt wird.
- Fehlerbehebung bei Problemen aufgrund geschlossener Cursor. Im Folgenden sehen Sie eine DB2-Ausnahme aus dem Protokoll "org.apache.openjpa.persistence.PersistenceException":
[ibm][db2][jcc][10120][10898] Invalid operation: result set is closed can be a WebSphere Application Server configuration problem.
Standardmäßig konfiguriert der Anwendungsserver die angepasste Eigenschaft "resultSetHoldability" mit dem Wert 2 (CLOSE_CURSORS_AT_COMMIT). Dieser Eigenschaft bewirkt, dass DB2 sein(en) resultSet/cursor an den Transaktionsgrenzen schließt. Trotz des DB2-Standardwerts 1 (HOLD_CURSORS_OVER_COMMIT) für resultSetHoldability, behält der Anwendungsserver den Standardwert 2 bei, um eine Beeinträchtigung der Kompatibilität mit früheren Releases des Anwendungsservers zu vermeiden. Sie können den Standardwert ändern.Achtung: Wenn diese Datenquelle eine XA-Datenquelle ist, definieren Sie eine neue angepasste Eigenschaft in der Datenquelle: Eigenschaftsname = downgradeHoldCursorsUnderXa und boolescher Wert = true.Fehler vermeiden: Wenn in Version 8.0 eine DB2-XA-Datenquelle verwendet wird, ist die folgende Konfiguration erforderlich, um das Problem result set closed zu beheben:
- Verwenden Sie DB2 Version 9.1 FP4 (für APAR IZ18072) oder eine höhere Version.
- Fügen Sie die angepasste Eigenschaft mit name="downgradeHoldCursorsUnderXa", value="true" und type="java.lang.Boolean" hinzu.
- Fügen Sie die angepasste Eigenschaft mit name="resultSetHoldability", value="1" und type="java.lang.Integer" hinzu.
- Vermeiden Sie eine Multithreadverwendung des EntityManager. Falls Sie
eine Ausnahme mit folgendem Nachrichtentext sehen, haben Sie möglicherweise versehentlich die Verwendung eines
EntityManager über mehrere Threads erlaubt. Pro JPA-Spezifikation sind EntityManager für die Verwendung durch einen einzelnen Einzelthread vorgesehen. Möglicherweise erhalten Sie eine Ausnahmebedingungsnachricht ähnlich der folgenden (in diesem Kontext sind Broker und EntityManager im Wesentlichen dasselbe):Dieses Problem kann auf mehrere Arten behoben werden:
Mehrere gleichzeitig ausgeführte Threads versuchten, auf einen einzelnen Broker zuzugreifen. Broker sind standardmäßig nicht threadsicher. Wenn mehrere Threads auf einen Broker zugreifen können sollen, setzen Sie die Eigenschaft openjpa.Multithreaded property auf true, um das Standardverhalten zu ändern.
Bewährtes Verfahren: Verwenden Sie das Muster get-use-close (abrufen-verwenden-schließen), wenn Sie anwendungsverwaltete (erweiterte) Persistenzkontexte verwenden. Denken Sie daran, den EntityManager zu schließen, bevor Sie die Methode verlassen, die den EntityManager verwendet hat. Wenn der EntityManager geöffnet bleibt, kann dies versehentlich bewirken, dass andere Threads dieselbe EntityManager-Instanz gleichzeitig verwenden und Systemressourcen belegen.bprac
- Ändern Sie die Anwendung in der Weise, dass sie CMP-Kontexte (Container-Managed Persistence) verwendet, indem Sie die EntityManager-Instanz über die Annotation @PersistenceContext einfügen, falls das Programmiermodell für die Anwendung für diese Änderung geeignet ist. Im Wesentlichen wird hierdurch das Muster get-use-close (abrufen-verwenden-schließen) durchgesetzt, indem dem Container die Verwaltung übertragen wird.
- Wie in diesem Ausnahmetext dokumentiert, kann OpenJPA für eine schnelle Ausweichlösung
so konfiguriert werden, das Multithread-Zugriff auf EntityManager mit der Eigenschaft
"openjpa.Multithreaded" angefordert wird.
Durch die Aktivierung dieser Eigeschaft kann unnötiger Aufwand entstehen.
Fehler vermeiden: Instanzvariablen für Servlets werden automatisch von allen Instanzen des Servlets gemeinsam genutzt. Die Verwendung der Annotation "@PersistenceContext" in einer Servletinstanzvariablen kann unabsichtlich zu einem Multithread-Zugriff auf denselben EntityManager führen. Außerdem werden alle auf diese Weise injizierten EntityManager vom Container nicht bereinigt, solange die Anwendung nicht gestoppt wird. Für Servlets ist die Verwendung der Annotation "@PersistenceUnit" für die Injektion einer EntityManagerFactory die bessere Wahl.gotcha
- Wenn Sie optimistisches Sperren verwenden, beachten Sie die Versionsbedingungen.
In der JPA-Architektur verwendet der Persistenzprovider die Eigenschaft "version", um
das optimistische Sperren und die Semantik für Parallelität für eine Persistenzentität durchzuführen, z. B.:
@Entity public class VersionedTimestampEntity { @Id private int id; @Version private java.sql.Timestamp version; .... }
Der Provider aktualisiert die Eigenschaft "version" mit einem neuen Wert, wenn eine Entität in die Datenbank geschrieben wird. Wenn eine Entität aufgenommen wird, prüft der Persistenzprovider die Versionseigenschaft, um festzustellen, ob die Entität, die aufgenommen wird, eine veraltete Kopie der Entität ist. Wenn die Operation aufgrund einer veralteten Versionsbedingung scheitert, tritt eine Ausnahme des Typs "OptimisticLockException" ein. Die gültigen Datentypen für die Eigenschaft "version" sind im Folgenden aufgelistet:- int
- Integer
- short
- Short
- long
- Long
- Timestamp
Wird eine Entität persistent gespeichert und anschließend in einem anderen Persistenzkontext, der innerhalb des Genauigkeitsfensters der Plattform liegt, abgerufen und aktualisiert, kann der Persistenzprovider die optimistische Sperre und den parallelen Zugriff nicht erkennen. Folglich kann eine Ausnahme des Typs OptimisticLockException ausgelöst werden, und die Datenintegrität kann beeinträchtigt sein.Fehler vermeiden: Wenn Sie den Typ "Timestamp" für die Eigenschaft "version" verwenden, muss die Anwendung das Verhalten beachten, das sich aufgrund der Implementierungsgenauigkeit ergibt, die für die Erstellung des Timestamp-Objekts verwendet wird. Die typische Implementierung verwendet die Methode "System.currentTimeMills". Die zeitliche Genauigkeit dieser Methode ist plattformspezifisch. Angenommen, die Genauigkeit ist 15 ms für 32- Bit-Windows und 2 ms für z/OS.gotcha
- Fehlerbehebung bei ungültigen Integritätsbedingungen in der Datenbank bei der Bearbeitung von Entitäten
Die mit WebSphere Application Server bereitgestellten JPA-Provider verwenden einen Update-Manager für Integritätsbedingungen, um die Reihenfolge der SQL-Anforderungen an die Datenbank basierend auf jeder Entitätskonfiguration zu bestimmen. Dieser Update-Manager kann die Reihenfolge der SQL-Anforderungen an die Datenbank ändern. Eine Anwendung muss somit die Reihenfolge der Operationen nicht kennen, die der Entitätenmanager ausführen muss, um seine Geschäftslogik auszuführen und die Datenbankleistung auf der Basis der zugrunde liegenden Stapelunterstützung zu optimieren.
Da der JPA-Provider nicht davon ausgeht, dass implizite Integritätsbedingungen für Beziehungen zwischen Entitäten vorliegen, setzt der JPA-Provider SQL-Anweisungen unter Umständen nicht in der gewünschten Reihenfolge ab, wenn es Integritätsbedingungen in der Datenbank gibt, z. B. eine Integritätsbedingung über Fremdschlüssel. In solchen Fällen können die folgenden oder ähnliche Ausnahmen eintreten:com.ibm.db2.jcc.b.SqlException: DB2 SQL error: SQLCODE: -530, SQLSTATE: 23503, SQLERRMC: xxxxxx
Dieses Problem kann auf mehrere Arten behoben werden:- Sie können den OpenJPA-Provider so konfigurieren, dass er Informationen zu Integritätsbedingungen aus der Datenbank liest und zur Laufzeit auf den Update-Manager
anwendet, indem Sie der Persistenzeinheit die folgende Konfigurationseigenschaft hinzufügen:
<property name="openjpa.jdbc.SchemaFactory" value="native(ForeignKeys=true)" />
- Die Anwendung kann die Entität so erweitern, dass sie die Annotation "@ForeignKey" verwendet, um dem
JPA-Provider die Beziehungen anzuzeigen, die Integritätsbedingungen über Fremdschlüssel haben.
public class Person { @ManyToOne @ForeignKey private Address address; .... }
- Für OpenJPA-Anwendungen kann die Anwendung die Zuständigkeit für die Sortierung der SQL-Anweisungen übernehmen, indem der Persistenzeinheit die folgende Konfigurationseigenschaft
hinzugefügt wird.
<property name="openjpa.jdbc.UpdateManager" value="operation-order" />
Wenn diese Konfigurationsoption definiert ist, führt der JPA-Provider die SQL-Anweisungen weiterhin in derselben Reihenfolge aus, in der die Entitätsoperationen angefordert wurden. Die Anwendung muss gegenseitige Abhängigkeiten zwischen Entitäten beachten.
Fehler vermeiden: Auch wenn Sie dazu neigen, eine Kombination dieser Eigenschaften zu verwenden, sollten Sie sich für die Eigenschaft entscheiden, die am besten zu Ihrer Situation passt. Wenn Sie eine Situation haben, in der Sie glauben, eine Kombination der Eigenschaften openjpa.jdbc.UpdateManager und openjpa.jdbc.SchemaFactory zu benötigen und diese auch verwenden, müssen Sie sich bewusst sein, dass Sie damit nicht unbedingt die Reihenfolge der SQL-Anforderungen erhalten, die für die Korrektur der Ausnahme erforderlich ist. Die Einstellung operation-order für die Eigenschaft openjpa.jdbc.UpdateManager zeigt dem JPA-Provider an, dass die SQL-Anforderungen in der Reihenfolge ausgeführt werden sollen, in der sie innerhalb einer Anwendung angegeben sind. Selbst wenn Sie die Eigenschaft openjpa.jdbc.SchemaFactory zusammen mit dem Befehl openjpa.jdbc.UpdateManager angeben, berücksichtigt der JPA-Provider die Reihenfolge der SQL-Anforderungen, die in einer Anwendung festgelegt ist, und führt keine automatische Sortierung von SQL-Anforderungen aufgrund einer ermittelten Integritätsbedingung (z. B. einer Integritätsbedingung über Fremdschlüssel) durch. Wenn die Eigenschaft openjpa.jdbc.UpdateManager angegeben ist, liegt es in der Verantwortung des Anwendungsentwicklers, sicherzustellen, dass die SQL-Anforderungen innerhalb einer Anwendung in der richtigen Reihenfolge angegeben sind. gotcha
- Entfernen Sie die Integritätsbedingungen aus der Datenbank.
- Sie können den OpenJPA-Provider so konfigurieren, dass er Informationen zu Integritätsbedingungen aus der Datenbank liest und zur Laufzeit auf den Update-Manager
anwendet, indem Sie der Persistenzeinheit die folgende Konfigurationseigenschaft hinzufügen:
- Beheben Sie Fehler mit der OpenJPA-ANT-Task "MappingTool".
Die ANT-Task "MappingTool", die von OpenJPA bereitgestellt wird, verwendet einen temporären Klassenlader, um die JDBC-Treiberklassen zu laden. Mit diesem temporären Klassenlader können Probleme beim Laden einiger JDBC-Treiber, z. B. für DB2, auftreten.
Wenn Sie die Ant-Task "MappingTool" ausführen, kann ein Fehler wie der folgende angezeigt werden:
[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)Zur Verwendung des Zuordnungstools können Sie den temporären Klassenlader inaktivieren, indem Sie der ANT-Task das Argument "tmpClassLoader=false" hinzufügen. Im Folgenden sehen Sie zwei ANT-Beispielscripts:
In diesem Beispiel tritt das Problem auf:
<taskdef name="mapping" classname="org.apache.openjpa.jdbc.ant.MappingToolTask" classpathref="jpa.cp"/> . . . <target name="map.broken"> <mapping> <!-- Hier tritt das Problem auf --> . . . </mapping> </target>
In diesem Beispiel tritt das Problem nicht auf:
<taskdef name="mapping" classname="org.apache.openjpa.jdbc.ant.MappingToolTask" classpathref="jpa.cp"/> . . . <target name="map.fixed"> <mapping tmpClassLoader="false"> <!-- Dieser Abschnitt funktioniert --> . . . </mapping> </target>
- Auswirkung von DataCache auf nicht konsistente Domänenmodelle
Wenn eine Anwendung ein inkonsistentes Domänenmodell als persistent definiert und die Entitäten später in einem gesonderten Persistenzkontext abruft, sind die abgerufenen Entitäten unterschiedlich, je nachdem, ob DataCache aktiv ist oder nicht.
Angenommen, es besteht eine bidirektionale Eins-zu-eins-Beziehung zwischen zwei Entitäten, die über eine einzige Fremdschlüsselspalte in der Datenbank zugeordnet werden. Eine Anwendung kann die Beziehungsfelder in den Entitäten inkonsistent definieren. Wenn der Datenbank solche inkonsistenten Werte zugeordnet werden, werden die Datenbankdatensätze nur konsistent, weil eine einzige Fremdschlüsselspalte angibt, dass der Datencache für bidirektionale Beziehungen aktiv ist. Aber dann erfasst der Datencache die inkonsistenten speicherinternen Entitätsstatus. Wenn eine Anwendung ein Entitätspaar, die über eine bidirektionale Relation miteinander verbunden sind, speichert, aber deren Relationsfelder auf inkonsistente Werte gesetzt sind, und die Anwendung die Entitäten später in einem anderen Persistenzkontext abruft, bleibt die bidirektionale Beziehung deshalb inkonsistent oder sie wird konsistent, je nachdem, ob der Datencache verwendet wird oder nicht.
Wenn mehrere Felder derselben Spalte zugeordnet sind, aber unterschiedliche Werte haben, wird ebenfalls ein inkonsistenter Entitätsstatus persistent definiert, aber als konsistenter Status in einem gesonderten Persistenzkontext abgerufen. Auch in diesem Fall bewirkt DataCache, dass die Entität in einem gesonderten Persistenzkontext realisiert wird, um unterschiedliche und inkonsistente Werte beizubehalten. Wenn DataCache nicht eingesetzt wird, enthält die Entität denselben Wert für beide Felder.
Bewährtes Verfahren: Vermeiden Sie inkonsistente Einträge im Anwendungsdomänenmodell. Für OpenJPA können Sie auch die Eigenschaft "openjpa.InverseManager" konfigurieren, um bestimmte Inkonsistenzen, wie z. B. bidirektionale Beziehungen, zu erkennen.bprac
- Probleme mit den Annotationen "MappingTool" und "@ForeignKey" mit Sybase beheben.
Das OpenJPA-Zuordnungstool kann keine Integritätsbedingungen über Fremdschlüssel erstellen, wenn Sybase Adaptive Server verwendet wird. Deshalb müssen die Integritätsbedingungen über Fremdschlüssel manuell erstellt werden.
- Beheben Sie Fehler bei den Konfigurationsoptionen für DB2 Optim pureQuery Runtime. Wenn Sie DB2 Optim pureQuery Runtime mit dem WebSphere Application Server-JPA-Provider (WSJPA) verwenden, müssen Sie die folgende Eigenschaft in der Datei persistence.xml definieren:
<property name="openjpa.Compatibility" value="StrictIdentityValues=true"/>
Wenn Sie eine andere Kompatibilitätsoption definieren müssen, z. B. ReloadOnDetach=false, müssen Sie beide Optionen als Parameter derselben Eigenschaftsanweisung in der Datei persistence.xml angeben. Beispiel:
<property name="openjpa.Compatibility" value="StrictIdentityValues=true,ReloadOnDetach=false"/>
Fehler vermeiden: Die Eigenschaft für die OpenJPA-Kompatibilität entfernt keine Proxy-Typen, die OpenJPA für bestimmte Datentypen generiert, insbesondere Datumstypen wie "GregorianCalendar" (gregorianischer Kalender). Diese Auslassung kann Probleme mit der Entserialisierung nach sich ziehen. Wenn ein Entserialisierungsfehler auftritt, wird eine Fehlernachricht wie die folgende ausgegeben: gotcha
Error Message is:org.codehaus.jackson.map.JsonMappingException: Can not construct instance of org.apache.openjpa.util.java$util$GregorianCalendar$proxy, problem: no suitable creator method found at [Source: org.apache.http.conn.EofSensorInputStream@d83fbd5; line: 1, column: 4094]
- Beheben Sie Fehler im Zusammenhang mit zeitrelevanten Typattributen in einer Entität, wenn Sie eine Datenbank mit
DB2 for z/OS verwenden möchten. Wenn eine Entität ein zeitrelevantes Typattribut hat und die entsprechende zugeordnete Spalte
für die Datenbank nicht kompatibel ist, wird in bestimmten Situationen möglicherweise die folgende Ausnahme angezeigt:
Diese Ausnahme wird möglicherweise angezeigt, wenn eine der folgenden Bedingungen zutrifft:org.apache.openjpa.lib.jdbc.ReportingSQLException: THE DATE, TIME, OR TIMESTAMP VALUE 1 IS INVALID. SQLCODE=-18x, SQLSTATE=22007
- Ihre Datenbank führt DB2 for z/OS aus.
- Sie verwenden eine benannte Abfrage und greifen mit nativem SQL auf die Datenbank zu.
- Die native Abfrage verwendet das zeitrelevante Feld als SQL-Parameter, die Abfrage ist jedoch nicht kompatibel mit der Spaltendefinition für die Datenbanktabelle. Weitere Informationen zur Kompatibilität finden Sie im Artikel Data conversions supported in CLI im Information Center von DB2 9.7.
Unterartikel
Anwendungen mit JPA protokollieren
Durch Protokollierung können Sie das Laufzeitverhalten einer Anwendung anzeigen, verfolgen und die dort auftretenden Fehler beheben. Java™ Persistence API (JPA) stellt ein in den Anwendungsserver integriertes flexibles Protokollierungssystem bereit, das Sie bei der Fehlerbehebung unterstützt.Fehlerbehebung bei JPA-Deadlocks und -Transaktionszeitlimitüberschreitungen
Datenbankdeadlocks und Transaktionszeitlimitüberschreitungen sind das Ergebnis von Konkurrenzsituationen zwischen zwei oder mehr Clients, die versuchen, auf dieselbe Datenbankressource zuzugreifen. Ein Deadlock ist ein spezieller Fall, bei dem eine blockierende Schleifenbedingung zwischen zwei oder mehr Clients vorliegt. Die Clients blockieren sich gegenseitig, und keiner der Clients kann seine Operation fortsetzen. Gewöhnlich sind diese Phänomene keine Programmierfehler. Sie werden durch Geschäftslogik verursacht, die auf komplexe Weise mit gegenseitigen Abhängigkeiten auf Datenbankressourcen zugreift.Anwendungen mit JPA protokollieren
Durch Protokollierung können Sie das Laufzeitverhalten einer Anwendung anzeigen, verfolgen und die dort auftretenden Fehler beheben. Java™ Persistence API (JPA) stellt ein in den Anwendungsserver integriertes flexibles Protokollierungssystem bereit, das Sie bei der Fehlerbehebung unterstützt.Fehlerbehebung bei JPA-Deadlocks und -Transaktionszeitlimitüberschreitungen
Datenbankdeadlocks und Transaktionszeitlimitüberschreitungen sind das Ergebnis von Konkurrenzsituationen zwischen zwei oder mehr Clients, die versuchen, auf dieselbe Datenbankressource zuzugreifen. Ein Deadlock ist ein spezieller Fall, bei dem eine blockierende Schleifenbedingung zwischen zwei oder mehr Clients vorliegt. Die Clients blockieren sich gegenseitig, und keiner der Clients kann seine Operation fortsetzen. Gewöhnlich sind diese Phänomene keine Programmierfehler. Sie werden durch Geschäftslogik verursacht, die auf komplexe Weise mit gegenseitigen Abhängigkeiten auf Datenbankressourcen zugreift.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tejb_jpatroubleshoot
Dateiname:tejb_jpatroubleshoot.html