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.
Recommandations pour l'utilisation des demandes d'écriture Gremlin dans Lambda
Si votre fonction Lambda modifie les données du graphe, envisagez d'adopter une back-off-and-retry stratégie pour gérer les exceptions suivantes :
-
ConcurrentModificationException: la sémantique des transactions Neptune signifie que les demandes d'écriture échouent parfois avec une exceptionConcurrentModificationException. Dans ces situations, essayez un mécanisme de back-off-based nouvelle tentative exponentielle. -
ReadOnlyViolationException: comme la topologie du cluster peut changer à tout moment en raison d'événements planifiés ou imprévus, les responsabilités d'écriture peuvent être transférées d'une instance du cluster à une autre. Si le code de la fonction tente d'envoyer une demande d'écriture à une instance qui n'est plus l'instance principale (d'enregistreur), cette demande échouera avec une exceptionReadOnlyViolationException. Dans ce cas, fermez la connexion existante, reconnectez-vous au point de terminaison du cluster, puis retentez la demande.
De plus, si vous utilisez une back-off-and-retry stratégie pour gérer les problèmes de demande d'écriture, envisagez d'implémenter des requêtes idempotentes pour les demandes de création et de mise à jour (par exemple, en utilisant fold () .coalesce () .unfold (
