Gestion des exceptions et nouvelles tentatives - Amazon Neptune

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Gestion des exceptions et nouvelles tentatives

Lorsque des transactions sont annulées en raison de conflits irrésolus ou de délais d'attente, Amazon Neptune répond par unConcurrentModificationException. Pour plus d'informations, consultez Codes d'erreur du moteur. En tant que bonne pratique, les clients doivent toujours intercepter et gérer ces exceptions.

Dans de nombreux cas, lorsque le nombre d'instances ConcurrentModificationException est faible, un mécanisme de nouvelle tentative basé sur un backoff exponentiel peut être utilisé avec succès pour les gérer. Dans ce type d'approche, le nombre maximal de nouvelles tentatives et de temps d'attente dépend généralement de la taille et de la durée maximales des transactions.

Toutefois, si votre application a des charges de mise à jour hautement simultanées et que vous observez un grand nombre d'événements ConcurrentModificationException, vous pouvez éventuellement modifier votre application afin de réduire le nombre de modifications simultanées en conflit.

Par exemple, imaginons une application qui effectue des mises à jour fréquentes sur un ensemble de sommets et utilise plusieurs threads simultanés pour ces mises à jour afin d'optimiser le débit d'écriture. Si chaque thread exécute en continu des requêtes qui mettent à jour une ou plusieurs propriétés de nœud, les mises à jour simultanées du même nœud peuvent produire des événements ConcurrentModificationException. Cela peut à son tour dégrader les performances d'écriture.

Vous réduirez considérablement la probabilité de telles conflits si vous pouvez sérialiser les mises à jour susceptibles d'entrer en conflit les unes avec les autres. Par exemple, si vous pouvez faire en sorte que toutes les requêtes de mise à jour pour un nœud donné soient effectuées sur le même thread (peut-être à l'aide d'une affectation basée sur le hachage), vous pouvez être sûr qu'elles seront exécutées l'une après l'autre plutôt que simultanément. Bien qu'il soit toujours possible qu'un verrouillage de plage effectué sur un nœud voisin puisse entraîner un événement ConcurrentModificationException, vous éliminez les mises à jour simultanées sur le même nœud.