Mengenal Race Condition dan Pessimistic Locking VS Optimistic Locking

4 min readOct 2, 2021

Sumber : https://nipunasilva.blogspot.com/2009/03/pessemestic-vs-optimistic-concurrency.html

Intro

Beberapa minggu lalu, saya mengikuti sebuah event CTF. kebetulan pada event tersebut terdapat challenge yang menarik yaitu race condition vulnerability. Sebenarnya saya sudah menemui challenge sejenis sebelumnya di event CTF lain sekitar setahun lalu. namun di CTF yang setahun lalu ini challenge dibangun dengan NodeJS (yang notabenenya JavaScript; berikut writeup challenge dari event setahun lalu), karena saya pribadi sering menemui bug race condition di Javascript di project saya pribadi yang sama-sama dibangun dengan JavaScript jadi saya tidak terlalu kaget. Hanya saja di event CTF yang baru beberapa minggu lalu ini cukup menarik bagi saya, karena saya tidak pernah kepikiran bahwa ternyata bug race condition ini dapat terjadi di Python dan bahkan di bahasa lainnya, PHP misalnya.

Karena penasaran, saya berpetualang di google dan forum-forum cara efektif untuk menanggulangi kasus ini. Ketemulah teknik yang efektif yaitu salah satunya dengan teknik locking yang terbagi menjadi 2 yakni : Pessimistic Locking atau Optimistic Locking https://www.2ndquadrant.com/en/blog/postgresql-anti-patterns-read-modify-write-cycles/.

Race Condition

Misalkan, ketika 2 atau lebih user ingin melakukan perubahan data pada record yang sama, maka akan sering terjadi konflik inilah yang biasa disebut dengan race condition. Dengan kata lain, pada concurrent proses, salah satu yang selesai duluan maka berhasil menang, dan yang lain akan mendapatkan error.

Bug ini kerap kali disalahgunakan oleh para hacker untuk mengeksploitasi sistem, dimana seharusnya user tersebut dapat melakukan suatu aksi sekali namun user mendapat keuntungan lain setelah melakukan aksi beberapa kali (secara simultan).berikut salah satu report bug bounty dengan mengeksploitasi bug tersebut (https://pravinponnusamy.medium.com/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43).

Untuk mengenal lebih jauh bug race condition dapat Anda baca di artikel

A hacker walks into a hookah lounge, an escape room, and a bar. The bartender says to him, “You have a race condition!”
Omar Ganiev

Pessimistic Locking

Supaya mudah dipahami, saya coba dengan pendekatan studi kasus. Semisal ada suatu aplikasi inventori barang, dimana dapat diakses oleh beberapa user yaitu USER A dan USER B.

Kedua user tersebut melakukan perubahan data pada record yang sama pada waktu yang bersamaan, sebagai berikut :

USER A mengambil data barang dengan ID = 1 (nama_barang = Tepung)
USER B mengambil data barang dengan ID = 1 (nama_barang = Tepung)
USER A update nama barang menjadi “Tepung terigu”
USER B update nama barang menjadi “Tepung tapioka”
USER A menyimpan perubahan data dan refresh, data barang yang didapat Tepung tapioka -_-
USER B menyimpan perubahan data dan refresh , data barang yang didapat Tepung tapioka ^_^

seperti itulah Pessimistic Locking, siapa yang terakhir dia yang menang, istilahnya “Last Commit Wins”.

Untuk implementasi pada framework laravel dapat dilihat pada dokumentasi https://laravel.com/docs/8.x/queries#pessimistic-locking

Optimistic Locking

Sama halnya dengan Pessimistic locking, supaya sama-sama mudah dipahami akan saya jelaskan dengan studi kasus saja.

USER A mengambil data barang dengan ID = 1 (nama_barang = Tepung)
USER B mengambil data barang dengan ID = 1 (nama_barang = Tepung)
USER A update nama barang menjadi “Tepung terigu”
USER B update nama barang menjadi “Tepung tapioka”
USER A menyimpan perubahan data dan refresh, data barang yang didapat Tepung tapioka
USER B menyimpan perubahan data namun gagal dan muncul pesan bahwa data sudah diubah

Karena saya programmer pawang gajah pengguna Laravel framework untungnya sudah ada package yang tersedia https://github.com/reshadman/laravel-optimistic-locking 😃.

Kesimpulan

Optimistic Locking adalah strategi dengan cara memeriksa record terlebih dahulu sebelum kita melakukan commit transaksi

Pessimistic Locking adalah ketika kita mengambil kuncian exclusive sehingga tidak ada orang lain yang dapat mulai memodifikasi record.

Optimistic Locking ini sangat berguna, dan berfungsi dengan baik bahkan saat menggunakan tingkat isolasi yang tidak terlalu strict.

Kelemahan dari Optimistic Locking adalah rollback akan dipicu oleh kerangka akses data setelah menangkap OptimisticLockException, oleh karena itu kemungkinan kita akan kehilangan pekerjaan yang telah dilakukan sebelumnya oleh transaksi yang sedang dijalankan saat itu.

Semakin banyak konflik atau bentrokan dan semakin besar peluang untuk membatalkan transaksi. Rollback bisa mahal untuk sistem database karena perlu mengembalikan semua perubahan yang sempat tertunda (pending).

Untuk alasan ini, Pessimistic Locking mungkin lebih cocok ketika konflik sering terjadi, karena mengurangi kemungkinan pembatalan transaksi.

Disisi lain, Pessimistic Locking juga kemungkinan dapat memicu terjadinya deadlock sehingga kurang tepat jika digunakan untuk mengatasi kasus race condition. link diskusi dapat Anda baca disini.

Jadi, mana yang lebih tepat, silahkan disesuaikan dengan kebutuhan dan kondisi project Anda.

Sekian dulu tulisan kali ini, ada kurang lebihnya mohon dikoreksi dan semoga tulisan bermanfaat 🙏. Terima kasih