Traitement des échecs de mises à jour en écriture différée

Etant donné que la transaction WebSphere eXtreme Scale se termine avant que la transaction expéditrice démarre, la transaction peut avoir un faux succès.

Si vous tentez d'insérer une entrée dans une transaction eXtreme Scale qui n'existe pas dans la mappe de sauvegarde, mais existe dans la base de données dorsale, entraînant ainsi une clé en double, la transaction eXtreme Scale aboutit. Cependant, la transaction dans laquelle l'unité d'exécution d'écriture différée insère l'objet dans la base de données du système dorsal échoue avec une exception de clé en double.

Traitement des échecs de mise à jour d'écriture différée : côté client

Ce type de mise à jour ou tout autre mise à jour dorsale ayant échoué est une mise à jour en écriture différée échouée. Les échecs de mises à jour en écriture différée sont stockés dans une mappe d'échecs de mises à jour en écriture différée. Cette mappe sert de file d'attente d'événements pour les mises à jour échouées. La clé de la mise à jour est un objet Integer unique et la valeur correspond à une instance de FailedUpdateElement. La mappe de mise à jour en écriture différée qui a échoué est configurée avec un expulseur qui expulse les enregistrements une heure après qu'il a été inséré. Ainsi, les enregistrements de mise à jour ayant échoué sont perdus s'ils ne sont pas récupérés sous une heure.

L'API ObjectMap peut être utilisée pour récupérer les entrées de mappe des échecs de mises à jour en écriture différée. Le nom de mappe de mise à jour eb écriture différée est : IBM_WB_FAILED_UPDATES_<map name>. Pour connaître le nom de préfixe de chacune des mappes système en écriture différée, reportez-vous à la documentation de l'API WriteBehindLoaderConstants. Voici un exemple.

échec de processus - exemple de code
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);
    // Faites quelque chose d'intéressant avec la clé, la valeur ou l'exception.

}
session.commit();

Un appel de la méthode getNextKey fonctionne avec une partition spécifique pour chaque transaction eXtreme Scale. Dans un environnement réparti, pour obtenir les clés de toutes les partitions, vous devez démarrer plusieurs transactions, comme le montre l'exemple suivant :

obtention des clés de toutes les partitions - exemple de code
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);
        // Faites quelque chose d'intéressant avec la clé, la valeur ou l'exception.

    }
    Session.commit();
}
Remarque : La mappe de mise à jour ayant échoué fournit un moyen de surveiller l'état de l'application. Si un système génère plusieurs enregistrements dans la mappe de mise à jour ayant échoué, cela indique que vous devez modifier l'application ou l'architecture pour utiliser l'écriture différée. Vous pouvez utiliser la commande xscmd -showMapSizes pour afficher la taille des entrées de mappe de mise à jour ayant échoué.

Traitement des échecs de mise à jour d'écriture différée : écouteur de fragments

La détection et la consignation des échecs de transactions en écriture différée sont importantes. Toutes les applications en écriture différée doivent implémenter un observateur pour traiter les échecs des mises à jour en écriture différée. Cette méthode permet d'éviter d'être à court de mémoire car les enregistrements d'une mappe d'échecs de mises à jour, censés être traités par l'application, ne sont pas expulsés.

Le code suivant montre comment se connecter à un observateur ou "videur," qui doit être ajouté au XML descripteur d'ObjectGrid comme dans le fragment.

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

Vous pouvez voir le bean ObjectGridEventListener qui a été ajouté et qui correspond à l'observateur d'écriture différé dont nous avons parlé plus haut. L'observateur interagit avec les mappes pour tous les fragments primaires d'une JVM à la recherche de ceux pour lesquels l'écriture différée a été activée. S'il trouve un fragment, il tente de consigner jusqu'à 100 échecs de mises à jour. Il observe en continu un fragment primaire jusqu'à ce que ce dernier soit déplacé vers une autre JVM. Toutes les applications utilisant l'écriture différée doivent utiliser un observateur similaire à celui-ci. Si ce n'est pas le cas, la mémoire de la machines virtuelles Java devient insuffisante car les enregistrements de cette mappe d'erreurs ne sont jamais expulsés.

Pour plus d'informations, voir Exemple : écriture d'une classe dumper en écriture différée.