Gestione di eccezioni e nuovi tentativi

Quando le transazioni vengono annullate a causa di conflitti non risolvibili o timeout di attesa del blocco, Amazon Neptune risponde con ConcurrentModificationException. Per ulteriori informazioni, consulta Codici di errore del motore. Come best practice, i client devono sempre catturare e gestire queste eccezioni.

In molti casi, quando il numero di istanze di ConcurrentModificationException è basso, un meccanismo di tentativi basato su backoff esponenziale è un metodo di gestione ideale. In questo approccio di tentativi, il numero massimo di tentativi e il tempo di attesa dipende generalmente dalle dimensioni massime e dalla durata delle transazioni.

Tuttavia, se l'applicazione dispone di carichi di lavoro di aggiornamento a elevata simultaneità e si osserva un numero elevato di eventi ConcurrentModificationException, puoi modificare l'applicazione per ridurre il numero di modifiche simultanee in conflitto.

Ad esempio, considera un'applicazione che effettua aggiornamenti frequenti a un set di vertici e utilizza più thread simultanei per questi aggiornamenti per ottimizzare il throughput di scrittura. Se ogni thread esegue continuamente query che aggiornano una o più proprietà del nodo, gli aggiornamenti simultanei dello stesso nodo possono produrre ConcurrentModificationException. Questo a sua volta può compromettere le prestazioni di scrittura.

È possibile ridurre notevolmente la probabilità di tali collisioni se è possibile serializzare gli aggiornamenti che potrebbero essere in conflitto tra loro. Ad esempio, se puoi garantire che tutte le query di aggiornamento per un determinato nodo vengano eseguite sullo stesso thread (magari utilizzando un'assegnazione basata su hash), puoi essere certo che verranno eseguite una dopo l'altra anziché simultaneamente. Anche se è comunque possibile che un blocco dell'intervallo eseguito su un nodo adiacente possa causare una ConcurrentModificationException, gli aggiornamenti simultanei allo stesso nodo vengono eliminati.