Verwenden Sie die folgenden Optionen, um Probleme mit Ihren Datenbankladeprogrammen (Loader) zu beheben.
Vorgehensweise
- Problem: Das Ladeprogramm kann nicht mit der Datenbank kommunizieren.
Es tritt eine Ausnahme des Typs LoaderNotAvailableException ein.
Erläuterung: Das Loader-Plug-in kann ausfallen, wenn
es nicht mit dem Datenbank-Back-End kommunizieren kann. Dieser Fehler kann auftreten, wenn der Datenbankserver
oder die Netzverbindung inaktiv ist.
Der Write-behind-Loader reiht die Aktualisierungen in eine Warteschlange ein und versucht anschließend in regelmäßigen Abständen, die Datenänderungen mit Push an den Loader
zu übertragen. Der Loader muss die ObjectGrid-Laufzeitumgebung darüber benachrichtigen, dass
ein Problem mit der Datenbankkonnektivität vorliegt, indem es eine Ausnahme vom Typ "LoaderNotAvailableException" auslöst.
Lösung: Die Loader-Implementierung muss in der Lage sein, einen Datenfehler
von einem physischen Ausfall des Loaders zu unterscheiden.
Bei Datenfehlern muss eine Ausnahme des Typs "LoaderException" oder "OptimisticCollisionException" ausgelöst bzw.
erneut ausgelöst werden, aber beim physischen Ausfall des Loaders muss eine Ausnahme des Typs
"LoaderNotAvailableException" ausgelöst werden.
ObjectGrid behandelt diese beiden Ausnahmen auf unterschiedliche Weise:
- Wenn eine LoaderException vom Write-behind-Ladeprogramm abgefangen wird,
stuft das Write-behind-Ladeprogramm die Ausnahme als Fehler ein, z. B. Fehler wegen doppelt vorhandenem Schlüssel.
Der Write-behind-Loader
löst den Aktualisierungsstapel auf und versucht, einen Datensatz nach dem anderen zu aktualisieren, um den Datenfehler zu isolieren.
Wird bei dieser Aktualisierung auf Datensatzbasis erneut eine Ausnahme vom Typ "LoaderException" abgefangen, wird ein Datensatz zur fehlgeschlagenen Aktualisierung erstellt und in der Map für fehlgeschlagene
Aktualisierungen protokolliert.
- Wenn der Write-behind-Loader eine Ausnahme vom Typ "LoaderNotAvailableException" abfängt, geht er
von einem Ausfall aus, weil er keine Verbindung zum Datenbank-Back-End herstellen kann, z. B., weil das Datenbank-Back-End
inaktiv ist, keine Datenbankverbindung verfügbar oder das Netz inaktiv ist.
Der Write-behind-Loader wartet 15 Sekunden und versucht dann erneut, die Datenbankaktualisierung im Stapelbetrieb durchzuführen.
Häufig wird der Fehler gemacht, eine Ausnahme vom Typ "LoaderException"
auszulösen, obwohl eigentlich eine Ausnahme vom Typ "LoaderNotAvailableException" ausgelöst werden müsste.
Alle Datensätze, die in die Warteschlange für den Write-behind-Loader
eingereiht sind, werden als Datensätze für eine fehlgeschlagene Aktualisierung markiert,
was den eigentlich Zweck der Isolierung von Back-End-Fehlern zunichte macht.
- Problem: Wenn Sie einen OpenJPA-Loader mit DB2 in WebSphere Application
Server verwenden,
tritt eine Ausnahme wegen geschlossener Cursor auf.
Die folgende Ausnahme in der org.apache.openjpa.persistence.PersistenceException-Protokolldatei stammt von DB2:
[jcc][t4][10120][10898][3.57.82] Invalid operation: result set is closed.
Lösung: Der Anwendungsserver
konfiguriert die angepasste Eigenschaft "resultSetHoldability" standardmäßig mit dem Wert
2 (CLOSE_CURSORS_AT_COMMIT).
Diese Eigenschaft bewirkt, dass DB2
seine Ergebnismenge bzw. seinen Cursor an Transaktionsgrenzen schließt. Zur Behebung der Ausnahme
ändern Sie den Wert der angepassten Eigenschaft
in
1
(HOLD_CURSORS_OVER_COMMIT). Definieren Sie die angepasste Eigenschaft "resultSetHoldability" über den folgenden Pfad in der Zelle von
WebSphere Application
Server: .
- Problem DB2 zeigt eine Ausnahme an:
The current transaction has been rolled back
because of a deadlock or timeout. Reason code "2".. SQLCODE=-911,
SQLSTATE=40001, DRIVER=3.50.152
Diese Ausnahme tritt aufgrund eines Sperrenkonflikts ein, wenn Sie
OpenJPA mit DB2 in WebSphere Application
Server ausführen.
Die Standardisolationsstufe für
WebSphere Application
Server ist "Repeatable Read (RR)" (wiederholbares Lesen), bei der
lange Sperren bei DB2 angefordert werden.
Lösung:
Setzen Sie die Isolationsstufe auf "Read Committed" (Lesen mit COMMIT), um die Sperrenkonflikte zu reduzieren.
Definieren Sie die angepasste Datenquelleneigenschaft "webSphereDefaultIsolationLevel",
um die Isolationsstufe auf 2(TRANSACTION_READ_COMMITTED)
über den folgenden Pfad in der Zelle von WebSphere Application
Server zu setzen:
. Weitere Informationen zur angepassten
Eigenschaft "webSphereDefaultIsolationLevel" und zu den Transaktionsisolationsstufen finden Sie unter
Voraussetzungen für das Festlegen von Isolationsstufen für Datenzugriff.
- Problem: Wenn Sie die Funktion für vorheriges Laden (Preload) von
JPALoader oder JPAEntityLoader verwenden, wird die folgende CWOBJ1511-Nachricht nicht für die Partition
in einem Container-Server angezeigt: CWOBJ1511I:
GRID_NAME:MAPSET_NAME:PARTITION_ID (primär) ist für Business bereit..
Stattdessen tritt eine Ausnahme des Typs "TargetNotAvailableException" im Container-Server ein, der die Partition
aktiviert, die mit der Eigenschaft "preloadPartition" angegeben wird.
Lösung: Setzen Sie das Attribut "preloadMode" auf
true, wenn Sie
einen JPALoader oder JPAEntityLoader für das vorherige Laden von Daten in die Map verwenden. Wenn die Eigenschaft
"preloadPartition" von JPALoader und JPAEntityLoader auf einen Wert zwischen
0 und
Gesamtpartitionsanzahl - 1 gesetzt ist,
versuchen JPALoader und JPAEntityLoader, die Daten vorher aus der Back-End-Datenbank in die Map zu laden.
Das folgende Code-Snippet veranschaulicht, wie das Attribut "preloadMode" so gesetzt wird,
dass das asynchrone vorherige Laden aktiviert wird:
BackingMap bm = og.defineMap( "map1" );
bm.setPreloadMode( true );
Sie können das Attribut "preloadMode" auch mithilfe einer XML-Datei definieren, wie im folgenden Beispiel
veranschaulicht wird:
<backingMap name="map1" preloadMode="true" pluginCollectionRef="map1"
lockStrategy="OPTIMISTIC" />