Penanganan Pengecualian dan Mencoba Lagi

Ketika transaksi dibatalkan karena konflik yang tidak terpecahkan atau lock-wait timeout, Amazon Neptune merespons dengan ConcurrentModificationException. Untuk informasi selengkapnya, lihat Kode Kesalahan Mesin. Sebagai praktik terbaik, klien harus selalu menangkap dan menangani pengecualian ini.

Dalam banyak kasus, ketika jumlah instans ConcurrentModificationException rendah, mekanisme retry berbasis backoff eksponensial bekerja dengan baik sebagai cara untuk menangani mereka. Dalam pendekatan coba lagi seperti itu, jumlah maksimum pengulangan dan waktu tunggu umumnya tergantung pada ukuran maksimum dan durasi transaksi.

Namun, jika aplikasi Anda memiliki beban kerja pembaruan yang sangat bersamaan, dan Anda mengamati sejumlah besar ConcurrentModificationException peristiwa, Anda mungkin dapat memodifikasi aplikasi Anda untuk mengurangi jumlah modifikasi bersamaan yang bertentangan.

Misalnya, pertimbangkan aplikasi yang sering memperbarui serangkaian simpul dan menggunakan beberapa tautan bersamaan untuk pembaruan ini guna mengoptimalkan throughput tulis. Jika setiap thread terus mengeksekusi kueri yang memperbarui satu properti simpul atau lebih, pembaruan bersamaan dari simpul yang sama dapat menghasilkanConcurrentModificationException. Hal ini pada gilirannya dapat menurunkan kinerja tulis.

Anda sangat dapat mengurangi kemungkinan bentrokan tersebut jika Anda memperbarui yang cenderung bertentangan satu sama lain secara bersambung. Sebagai contoh, jika Anda dapat memastikan bahwa semua kueri pembaruan untuk simpul yang diberikan dibuat pada utas yang sama (mungkin menggunakan tugas berbasis hash), Anda dapat yakin bahwa mereka akan dieksekusi satu demi satu daripada secara bersamaan. Meskipun masih mungkin bahwa kunci rentang yang diambil pada simpul tetangga dapat menyebabkan ConcurrentModificationException, Anda menyingkirkan pembaruan bersamaan ke simpul yang sama.