Tratamento de exceções e novas tentativas

Quando as transações são canceladas devido a conflitos não resolvidos ou a tempos limite de espera de bloqueio, o Amazon Neptune responde com um ConcurrentModificationException. Para ter mais informações, consulte Códigos de erro do mecanismo. Como melhor prática, os clientes sempre devem capturar e lidar com essas exceções.

Em muitos casos, quando o número de instâncias ConcurrentModificationException é baixo, um mecanismo de repetição baseado em recuo exponencial funciona bem como uma maneira de lidar com elas. Nessa abordagem de repetição, o número máximo de novas tentativas e de tempo de espera geralmente depende do tamanho máximo e da duração das transações.

No entanto, se seu aplicativo tiver cargas de trabalho de atualização altamente simultâneas, e você observar um grande número de eventos ConcurrentModificationException, poderá modificar o aplicativo para reduzir o número de modificações simultâneas conflitantes.

Por exemplo, considere um aplicativo que faz atualizações frequentes em um conjunto de vértices e usa vários threads simultâneos para essas atualizações a fim de otimizar a taxa de transferência de gravação. Se cada thread executar continuamente consultas que atualizam uma ou mais propriedades de nó, as atualizações simultâneas do mesmo nó poderão produzir ConcurrentModificationExceptions. Isso, por sua vez, pode degradar o desempenho de gravação.

Você pode reduzir significativamente a probabilidade de tais colisões se puder serializar atualizações que provavelmente entrarão em conflito entre si. Por exemplo, se você puder garantir que todas as consultas de atualização de um determinado nó sejam feitas no mesmo thread (talvez usando uma atribuição baseada em hash), poderá ter certeza de que elas serão executadas uma após a outra em vez de simultaneamente. Embora ainda seja possível que um bloqueio de intervalo obtido em um nó vizinho possa causar uma ConcurrentModificationException, você elimina atualizações simultâneas no mesmo nó.