Control de excepciones y reintentos - Amazon Neptune

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Control de excepciones y reintentos

Cuando las transacciones se cancelan debido a conflictos que no se pueden resolver o a tiempos de espera de bloqueo, Amazon Neptune responde con un ConcurrentModificationException. Para obtener más información, consulte Códigos de error del motor. Como práctica recomendada, los clientes siempre deben detectar y gestionar estas excepciones.

En muchos casos, cuando el número de instancias ConcurrentModificationException es bajo, un mecanismo de reintento exponencial basado en retardo funciona bien como una forma de gestionarlas. En este enfoque de reintento, el número máximo de reintentos y el tiempo de espera suele depender del tamaño y la duración máximos de las transacciones.

Sin embargo, si la aplicación tiene cargas de trabajo de actualización muy simultáneas y observa un gran número de eventos ConcurrentModificationException, es posible que pueda modificar la aplicación para reducir el número de modificaciones simultáneas en conflicto.

Por ejemplo, elijamos una aplicación que realiza actualizaciones frecuentes en un conjunto de vértices y utiliza varios subprocesos simultáneos para estas actualizaciones con el fin de optimizar el rendimiento de escritura. Si cada subproceso ejecuta continuamente consultas que actualizan una o varias propiedades de nodo, las actualizaciones simultáneas del mismo nodo pueden producir ConcurrentModificationExceptions. Esto, a su vez, puede reducir el rendimiento de escritura.

Puede disminuir en gran medida la probabilidad de este tipo de colisiones si puede serializar actualizaciones que es probable que entren en conflicto entre sí. Por ejemplo, si puede asegurarse de que todas las consultas de actualización de un nodo determinado se realicen en el mismo subproceso (quizás mediante una asignación basada en hash), puede estar seguro de que se ejecutarán una tras otra en lugar de simultáneamente. Aunque sigue siendo posible que un bloqueo de rango tomado en un nodo vecino pueda provocar una exepción ConcurrentModificationException, se eliminarán las actualizaciones simultáneas del mismo nodo.