Behandlung fehlgeschlagener Write-behind-Aktualisierungen

Da die Transaktion von WebSphere eXtreme Scale vor dem Start der Back-End-Transaktion beendet wird, kann beendet wird, ist es möglich, dass eine erfolgreiche Transaktion berichtet wird, obwohl dies in Wirklichkeit nicht der Fall ist.

Wenn Sie versuchen, einen Eintrag in eine eXtreme-Scale-Transaktion einzufügen, die nicht in der BackingMap, aber in der Back-End-Datenbank vorhanden ist, was einen doppelten Schlüssel zur Folge hat, ist die eXtreme-Scale-Transaktion erfolgreich. Die Transaktion, in der der Write-behind-Thread das Objekt in die Back-End-Datenbank einfügt, scheitert jedoch mit einer Ausnahme vom Typ "Schlüssel doppelt vorhanden".

Behandlung fehlgeschlagener Write-behind-Aktualisierungen: Clientseite

Eine solche Aktualisierung und jede andere fehlgeschlagene Back-End-Aktualisierung ist eine fehlgeschlagene Write-behind-Aktualisierung. Fehlgeschlagene Write-behind-Aktualisierungen werden in einer Map für fehlgeschlagene Write-behind-Aktualisierungen gespeichert. Diese Map dient als Ereigniswarteschlange für fehlgeschlagene Aktualisierungen. Der Schlüssel der Aktualisierung ist ein eindeutiges Integer-Objekt, und der Wert ist eine Instanz von FailedUpdateElement. Die fehlgeschlagene Write-behind-Aktualisierungs-Map ist mit einem Evictor (Bereinigungsprogramm) konfiguriert, der die Datensätze eine Stunde nach Einfügen entfernt. Deshalb gehen Datensätze der fehlgeschlagenen Aktualisierung verloren, wenn sie nicht innerhalb von einer Stunde abgerufen werden.

Mit der API "ObjectMap" können die Map-Einträge für fehlgeschlagene Write-behind-Aktualisierung abgerufen werden. Die Map für fehlgeschlagene Write-behind-Aktualisierungen hat den Namen IBM_WB_FAILED_UPDATES_<Map-Name>. Die Präfixnamen für die einzelnen Write-behind-System-Maps finden Sie in der Dokumentation zur API "WriteBehindLoaderConstants". Es folgt ein Beispiel.

Prozess fehlgeschlagen - Beispielcode
ObjectMap failedMap = session.getMap(
    WriteBehindLoaderConstants.WRITE_BEHIND_FAILED_UPDATES_MAP_PREFIX + "Employee");
Object key = null;

session.begin();
while(key = failedMap.getNextKey(ObjectMap.QUEUE_TIMEOUT_NONE)) {
    FailedUpdateElement element = (FailedUpdateElement) failedMap.get(key);
    Throwable throwable = element.getThrowable();
    Object failedKey = element.getKey();
    Object failedValue = element.getAfterImage();
    failedMap.remove(key);
    // Schlüssel, Wert oder Ausnahme verarbeiten

}
session.commit();

Ein Aufruf der Methode getNextKey arbeitet für jede eXtreme-Scale-Transaktion mit einer bestimmten Partition. In einer verteilten Umgebung müssen Sie zum Abrufen der Schlüssel aus allen Partitionen mehrere Transaktionen starten, wie im folgenden Beispiel gezeigt wird:

Schlüssel von allen Partitionen abrufen - Beispielcode
ObjectMap failedMap = session.getMap(
    WriteBehindLoaderConstants.WRITE_BEHIND_FAILED_UPDATES_MAP_PREFIX + "Employee");
while (true) {
    session.begin();
    Object key = null; 
    while(( key = failedMap.getNextKey(5000) )!= null ) {
        FailedUpdateElement element = (FailedUpdateElement) failedMap.get(key);
    Throwable throwable = element.getThrowable();
        Object failedKey = element.getKey();
        Object failedValue = element.getAfterImage();
        failedMap.remove(key);
        // Schlüssel, Wert oder Ausnahme verarbeiten

    }
    Session.commit();
}
Anmerkung: Die Map für fehlgeschlagene Aktualisierungen ist eine Möglichkeit, die Vitalität (den ordnungsgemäßen Betrieb) der Anwendung zu überwachen. Wenn ein System sehr viele Datensätze in der Map für fehlgeschlagene Aktualisierungen erzeugt, ist dies ein Hinweis darauf, dass Sie die Anwendungsarchitektur so überarbeiten müssen, dass die Write-behind-Unterstützung genutzt wird. Sie können den Befehl xscmd -showMapSizes verwenden, um die Größe von Einträgen in der Map für fehlgeschlagene Aktualisierungen anzuzeigen.

Behandlung fehlgeschlagener Write-behind-Aktualisierungen: Shard-Listener

Eine fehlgeschlagene Write-behind-Transaktion sollte unbedingt erkannt und protokolliert werden. Jede Anwendung, die die Write-behind-Technik verwendet, muss einen Watcher (Überwachungsprogramm) für die Behandlung fehlgeschlagener Write-behind-Aktualisierungen implementieren. Auf diese Weise kann ein Speicherengpass verhindert werden, wenn Datensätze in der Map für fehlgeschlagene Aktualisierungen nicht entfernt werden, weil die Bereinigung durch die Anwendung erwartet wird.

Der folgende Code veranschaulicht, wie ein solcher Watcher oder Dumper integriert wird, der wie im folgenden Snippet der ObjectGrid-Deskriptor-XML hinzugefügt werden muss:

<objectGrid name="Grid">
	        <bean id="ObjectGridEventListener" className="utils.WriteBehindDumper"/>

Wie Sie sehen, wurde die die Bean "ObjectGridEventListener" hinzugefügt. Diese Bean ist der zuvor erwähnte Write-behind-Watcher. Der Watcher interagiert mit den Maps für alle primären Shards in einer JVM und sucht nach denen, in denen die Write-behind-Technik aktiviert ist. Wenn er ein solches Shard findet, versucht er, bis zu 100 fehlgeschlagene Aktualisierungen zu protokollieren. Er überwacht ein primäres Shard so lange, bis das Shard in eine andere JVM verschoben wird. Alle Anwendungen, die die Write-behind-Technik verwenden, müssen einen Watcher verwenden, der diesem gleicht. Andernfalls kann in den Java Virtual Machines ein Speicherengpass auftreten, weil die Fehler-Map nie bereinigt wird.

Weitere Informationen finden Sie im Artikel Beispiel: Write-behind-Dumper-Klasse schreiben.