예외 처리 및 재시도

해결할 수 없는 충돌이나 잠금-대기 제한 시간으로 인해 트랜잭션이 취소되면 Amazon Neptune이 ConcurrentModificationException로 응답합니다. 자세한 정보는 엔진 오류 코드을 참조하세요. 모범 사례에 따라 클라이언트는 이러한 예외를 항상 포착해 처리해야 합니다.

많은 경우에 ConcurrentModificationException 인스턴스의 수가 적으면 예외적인 백오프 기반의 재시도 메커니즘이 이를 처리하기 위한 방법으로서 잘 작동합니다. 이러한 재시도 접근 방식에서 최대 재시도 횟수 및 대기 시간은 보통 트랜잭션의 최대 크기와 지속 시간에 따라 결정됩니다.

그러나 애플리케이션에 동시성이 높은 업데이트 워크로드가 포함되어 있고 ConcurrentModificationException 이벤트가 다수 관찰되는 경우에는 충돌하는 동시 수정 작업의 수를 줄이기 위해 애플리케이션을 수정할 수 있습니다.

예를 들어 버텍스 집합을 자주 업데이트하고 쓰기 처리량을 최적화하기 위해 이러한 업데이트에서 여러 개의 동시 스레드를 사용하는 애플리케이션이 있다고 가정해 보십시오. 각 스레드가 노드 속성을 하나 업데이트하는 쿼리를 계속해서 실행하면 동일 노드에 대한 동시 업데이트로 인해 ConcurrentModificationException이 생성될 수 있습니다. 이렇게 되면 쓰기 성능이 저하됩니다.

상호 충돌을 야기할 수 있는 업데이트를 직렬화하면 이러한 충돌 가능성을 대폭 줄일 수 있습니다. 예를 들어 주어진 노드에 대한 모든 업데이트 쿼리가 동일한 스레드에 대해 이루어지도록 할 수 있으면(아마도 해시 기반 할당을 사용) 업데이트가 동시가 아닌 차례대로 실행되도록 할 수 있습니다. 이웃 노드에 대해 범위 잠금을 적용하면 ConcurrentModificationException을 야기할 가능성은 여전히 있지만, 동일 노드에 대한 동시 업데이트를 막을 수 있습니다.