Bagaimana Race Condition Terjadi di Database?

[@BudyKIr]

Cara kedua di NoSQL itu basically adalah Optimistic Locking biasa jg di terapkan di SQL dan di bnyak cases lebih cocok jg terapin Optimistic Lock,,,biasanya pakai cara additional condition atau row versionning

[@hafidhpradipta8446]

Sebenernya ada cara lain untuk handling race condition (secara lebih universal) yang berkaitan dengan update database, yaitu pake schema versioning. Cara ini harus nambahin column version (default nya 1). Nah nanti pas waktu melakukan update misal ada 2 request yang masuk bersamaan dan mengacu pada kolom-kolom yang sama kita lakukan query kurang lebih gini UPDATE table SET column=value, version=version + 1 WHERE user=eko AND version=oldversion; kita mengupdate column yang ingin diubah dan increment version nya dengan 1 tetapi kondisi version nya yang lama. Sehingga jika request pertama yang dipilih oleh DB maka request kedua akan failed karena version sudah berubah. #JustSharing.

[@ProgrammerZamanNow]

Strategi itu namanya optimistic locking, mirip seperti solusi kedua yg saya bahas

[@hafidhpradipta8446]

​@@ProgrammerZamanNow iya bener kang, optimistic locking update.

[@muhammadsalbiyath4212]

Tapi kang, kalo request itu berbarengan kan nanti mereka versionya pasti sama posisinya. Saya pernah coba ini dan pas ditest 2 request itu punya value version yg sama. Nah itu gmana ya?

[@hafidhpradipta8446]

@@muhammadsalbiyath4212 iya emg gitu cara kerjanya, ada dua versi sama yg masuk. yang pertama duluan ke update (success), yang kedua akan fail karena version udah ga sama lagi (udah di increment dari percobaan yang pertama)

[@Blazeplay20]

solusi yang bagus bngt nih

[@nurcahyaari]

Biasanya saya kalo handle race condition pake distributed lock di level service layernya. cuman case race condition ini masih jadi hal yang menurut saya agak susah, terutama di level performance. karena race condition ini harus dihandle dengan cara ngebikin kondisi itu enggak async, tapi sync. karena sync impact nya ke performance. semisal 1 request makan 100ms, timeout 60s. ada concurrent processes sebanyak 601, otomatis data yang ke 601 pasti kena timeout. udah gitu masing masing proses mulai ke 50 keatas udah pasti akan terasa lama, karena prosesnya masih nyangkut nunggu unlocked

[@ProgrammerZamanNow]

Betul, tujuan lock biar data aman, jadi performance dikorbankan

[@margonogono6973]

Terima kasih.

[@ProgrammerZamanNow]

thanks

[@muhammadyusufmalik9248]

Gabut gabisa tidur malah nonton konten yg isinya daging. Makasih mas eko 😁

[@aliif]

thx pak, pemahaman baru bagi saya untuk versi nosql nya

[@asprjl]

Seru nih race condition, Dlu sya coba terapin optimistic locking dan untuk dapat test case nya pake jmeter concurrent request

[@LatenightDev]

Terimakasih bang untuk penjelasannya.

[@rahmatamrif775]

Terima kasih ilmunya pak 🙏🙏

[@rayvid7979]

dulu juga pernah ada kasus aneh di database saya. data di satu table selalu telat update mungkin karena volumenya udah kebanyakan. fixnya cuman pake cara jadul doank. bisnis logicnya dipindahin ke db pake stored procedure dan ORMnya dibuang semua ganti pake jdbc yang panggil stored procedure.

[@MulkanSyarifSTP]

Waah penjelasan yg clear sekali

[@kuntetdilaga5031]

Mantap, lagi kena masalah ini, eh muncul videonya, makasih banyak kang 🙏

[@ProgrammerZamanNow]

semoga bermanfaat

[@permanadiningrat]

saya biasanya untuk penanganan awal handling by redis, bikin util manggil setNX, 2 request secara bersamaan sebelum masuk database sudah dilarang , hanya 1 yang akan berhasil

[@Rifal15]

jika menggunakan trigger apa masih bisa kena masalah race condition ?

[@fhmisml]

pak eko bahas pooling utk spring boot yg best practice dong, kadang ada app yg querynya blm optimal, atau kadang bikin nyangkut di pool dll. Paling sering nemu issue HikariPoll - Connection is not available 😅

[@farisdewantoro5069]

Cara lain bisa jg pakai redis-lock, jadi ketika ada user yang ingin melakukan transaction kita cek dulu user-id tersebut sedang di proses atau tidak, kalo key nya exist artinya sedang di proses kalo tidak lock key nya

[@ahmadganteng7435]

Keren idenya..

[@dev9033]

kalau ditempat saya menggunakan skema balance locked dan balance available, dimana ketika proses transaksi akan dilakukan pemindahan balance dari avaibale ke locked

[@alfuady]

wah mantap sekali ini pak eko, saya sempat cari2 juga bahasan seperti ini sebelum2 nya untuk problem di sistem yang saya bikin, tp saya masih bingung sampai saat ini masih sering terjadi miss data tersebut walaupun sudah menggunakan DBTrx , yaa meskipun lebih jarang dari yang sebelum2 nya, permasalah awal saya karena memang bugs di coding nya karena ada proses integrasi ke 3rd party, dan akhirnya benar2 saya pisahkan proses nya, namun entah kenapa masih aja suka terjadi 2-3 kali, apakah ada yang mengalami hal yang sama jg?

[@projo27]

Makasih bang

[@jayjolupoi88891]

Mantap Mas, terima kasih wejangannya

[@abzalomkyeuwkyeuw]

Kalo di laravel mudah di tangani dengan Cache Lock

[@fathur208]

Kang mau tanya, klo kita pakai arsitektur microservices berbasis API apakah bisa melakukan transaction locking? Atau apakah harus menggunakan basis event driven?

[@akhmadnurmuhammad7148]

pak, kalo kita begin with isolation level serialize query selectnya perlu for update juga ga ya? thanks for answer

[@yogipristiawan3899]

gaperlu. tapi perlu nambahin mekanisme retry

[@yogipristiawan3899]

gaperlu. tapi perlu nambahin mekanisme retry

[@yogipristiawan3899]

gaperlu. tapi perlu nambahin mekanisme retry

[@yogipristiawan3899]

gaperlu. tapi perlu nambahin mekanisme retry

[@Rhidayah]

Oh jd ini yg namany race condition,, wkwk dulu nge abuse nickname facebook. Jd teknikny sprti itu di tabrakin 2 input. Tujuan abuse nickname. Buat bkin akun hantu. Jdi stiap orng yg mengunjungi akun kita, bkl 404 not found wkwk

[@nat_peterson47]

Bang, gimana cara handle transactional request.. untuk microservice. Best practice mekanisme untuk nge rollback ke setiap service

[@ProgrammerZamanNow]

SAGA Patterns

[@Giburozu]

Permisi pak mau tanya. Apakah fitur like seperti instagram juga termasuk race condition? Terimakasih semoga dijawab

[@indoprintingdevops3312]

Secara global untuk meng-handle Race Condition adalah menggunakan teknik Mutual Exclusion, di mana jika terjadi request secara simultan, hanya ada satu request yang dapat diproses dan request lainnya harus menunggu sampai request pertama tadi selesai. Teknik ini tidak bergantung pada bahasa pemrograman tertentu. Tapi bisa diimplementasikan hampir disemua bahasa pemrograman.

[@egipebriyawan1455]

cara melakukan req simultan nya ituo gimana ya ms ? apa kalau dicontoh ini pakai apps dan web secara bersamaan pakai 1 akun ?

[@tyohary2284]

Klo preventif nya di level app nya susah bang, misal app nya running on multiple container, beda container beda mutex

[@aryaadinulfadlan8998]

wah gimana tu pak detect nya disisi app / bahasa pemrograman?

[@herlianzhang6125]

apakah kita perlu Handling Race Condition di semua data atau hanya untuk yang critical saja (seperti saldo, point, dll)?

[@ProgrammerZamanNow]

bagusnya di semua hal, tapi kalo sulit, di hal-hal yang sangat penting

[@nightking896]

terima kasih pak eko

[@lionelnahormoata4020]

Kasusnya kaya saya persis ini waktu pake salah 1 e-wallet pesen double order food tapi saldo masih blm kepotong persis bgt kaya race condition, tapi kayanya skrg udah diupdate sama developnya, jadi begitu mau double order, yang 1 langsung ke update(saldo langsung terpotong).

[@ProgrammerZamanNow]

anda kurang beruntung

[@Ferifroyo]

​@@ProgrammerZamanNow adalagi gak Pak Echo cara lainnya biar bisa dapat gratisan cuma2 😊😅

[@egipebriyawan1455]

definisinya double order tuh gimana ya Mas ? masih pemula maaf.

[@davidimannuel6639]

untuk penangan locking buat no SQL setahu saya itu namanya optimistic locking,saya mau bertanya apakah boleh juga pak menerapkan optimistic locking pada relational database, dan apakah secara performa sama saja dengan menggunakan row level locking (select for update)+ db trx ?

[@ProgrammerZamanNow]

boleh banget, bisa optimistic locking bisa dimana aja

[@davidimannuel6639]

@@ProgrammerZamanNow thx info pak 🙏

[@rezavanessa4284]

@@ProgrammerZamanNow kalo pake optimistic locking bisa kena deadlock ga pak?

[@yogipristiawan3899]

pakai database isolation level juga bisa. alih alih pakai locking

[@darl_04]

Mantap pak eko bermanfaat banget ilmunya, baru tahu bisa gitu ternyata

[@vanetti8771]

Bagus

[@ShortTani]

Semua database punya fungsi untuk menangani race condition, biasanya lock/start/begin -commit-rollback. Tinggal bagaimana kita memanfaatkannya secara benar. Beberapa saya temui, mereka kesulitan menggunakan "start-commit/rollback" jika melibatkan banyak table.

[@VinaPrilli]

Bener pada kesulitan make fitur mysql start trnsaction

[@aryaadinulfadlan8998]

kalo di no SQL bisa locking juga ya?

[@ShortTani]

@@aryaadinulfadlan8998 nosql banyak jenisnya, belum pernah butuh nosql jadi saya jawab "tidak tahu". Tapi harusnya ada, karena ini adalah fungsi dasar.

[@harisoche]

mau tanya mas klw misalkan pake relational terus pke transactional dan di lock, apakah ketika ada proses lain yg select ke table yg sama dia jadi ikut nunggu juga? klw misalkan iya nnti proses yg lain jadi ikut antri dan bisa nyebabin aplikasi jdi lebih lambat response-nya. Bener gtu ga ?

[@rumahbejo]

Ada kasus untuk firebase realtime dan firestore ? .

[@FeriyadiI-c7z]

Untuk kasus NoSQL, misal kasus begini: Eko saldo 1000 transaksi: A -> 700 B -> 100 C -> 800 Kalau dengan WHERE saldo 1000 nanti transaksi B fail kan ya, yang seharusnya sukses karena saldo masih sisa. kira-kira gmn ya? Thanks

[@TriAriSetiawan]

mungkin where jika saldo > nilai_transaksi

[@ProgrammerZamanNow]

anggap urutannya A, B, dan C, otomatis B dan C fail, karena saldo udah tidak 1000 lagi

[@FeriyadiI-c7z]

​@@ProgrammerZamanNow Tapi transaksi B secara nominal harusnya success kan ya mas, karena nilai transaksinya masih dibawah saldo.

[@the-antroy]

betul, karena B < saldo = 300

[@JemikaNegara]

​@@FeriyadiI-c7z mungkin bisa retry cek saldo lagi mas, kalau saldo masih bisa dideduct coba set ulang, kalau saldo tidak mencukupi baru kirim error ke user

[@rezavanessa4284]

Pak izin bertanya.. itu lock for update mengunci semua database ? Jadi kalo user pertama lagi nerapin lock for update, user yang kedua bisa query select ke database gak ? Apa harus nunggu user pertama selesai melakukan operasi lock for update ?

[@MrSundaayy]

dari dulu sempet kepikiran begini sih, ternyata istilahnya ini dan cara menanganinya begitu. Kalo sistem flashsale di marketplace itu pake ini juga ya?

[@egipebriyawan1455]

harusnya iya ya, kalau gak pake locking amsyong iphone kuotanya 10 tapi yang berhasil checkout 1000 orang 😁

[@egipebriyawan1455]

harusnya iya ya, kalau gak pake locking amsyong iphone kuotanya 10 tapi yang berhasil checkout 1000 orang 😁

[@didi_abdillah]

nah ini yang yang saya suka overthinking jika web saya banyak sudah usernya.

[@exelfer081]

Entahlah, klo di nosql kita bisa get saldo terakhir baru validasi, dan di update...

[@trisna_cb]

Mas, untuk saldo itu memang bagusnya disimpen di field ya mas? Soalnya saya ngitung saldo manual, select sum income - expense Apa dampaknya kalo misalkan saya terus menggunakan metode itu dalam hal saldo?

[@ProgrammerZamanNow]

kalo transaksinya udah ratusa ribu kali gimana?

[@trisna_cb]

@@ProgrammerZamanNow nah itu kurang tahu mas, apakah database nya akan semakin lambat saat query select sum(debit)-sum(kredit)?

[@arwahsapi]

Kalau kecil cukup pakai materialized view kalau engine database nya support (Oracle, PostgreSQL, dll) dan di scheduled refresh. Kalau besar diwarehousekan dulu via ETL.

[@GalihAlHakim-pq6el]

bang tanya nih, kalo misal ini katakan lah saldonya cukup yaa untuk 3 transaksi tadi dan 3 transaksi tadi jalan barengan. apabila nanti diupdate saldonya pakek query jumlah saldo terakhir, berarti yg mana transaki pertama berhasil dan transaksi kedua dan ketiga gagal juga yaa?

[@farrel6788]

Kurang paham yang dateng 3 request berbarengan, emang web server bakal ngehandle 3 request itu bareng2 bukan selesain satu2?

[@didi_abdillah]

kalau dari Compiler Bahasa Pemrograman umumnya single thread, tapi karena Web Server lah yang ngejalanin dengan multi thread sampai batas kemampuan baik hardware atau software tersebut, dan itu masuk akal apalagi untuk server dengan user yang ribuan hingga jutaan, kalau di set pakai single thread doang jadinya nanti delay antrian.

[@egipebriyawan1455]

gini mungkin mas maksdnya, dateng 3 request trx . nah request itu ada 3 tahap 1. cek harga 2. validasi saldo apakah cukup atau tidak. 3. update saldo. nah kecolongannya adalah ketika proses update saldo belum selesai . request lain udah masuk di validasi, yang mana saldo belum selesai diupdate . jadi bisa kecolongn. yang saya bingung justru gimana caranya melakukan 3 request secara bersamaan . haha .. kalau salah maaf ya ..

[@rayvid7979]

ane juga bingung. 3 request itu pasti diproses satu per satu (FIFO) di web/app servernya. di database server juga begitu. apalagi kalo dbnya sekelas oracle, sql server. dijamin gak bakal kejadian tuh kondisi begitu.

[@muhammadwidyan4413]

kalau pakai queue seperti kafka untuk handle race condition apakah bisa kang?

[@SeptAndro]

Barusan aplikasi gue kena kondisi seperti ini, akhirnya saldo jebol, untung masih bisa terdeteksi

[@Masheru14]

Nice

[@fauzifadhillah3222]

kalo aku biasanya di postgres, pake decrement update table set saldo = saldo - 1000 where user_id = 1 terus di combine sama constraint check di db 'saldo > 0' bisa juga kan ya temen temen? ato tetep ada bolongnya?

[@ahmadganteng7435]

Masuk akal juga.. Keren..

[@luckyardhika3781]

tetep bolong bg kalo saldonya ada 100k, tetep masuk kualifikasi saldo > 0

[@ibnufachrizal]

aku pernah pentest di ewallet beli gpc 1jt cuma bayar 20k pake metode race condition di burp turbo intruder

[@ProgrammerZamanNow]

🔥

[@luckyardhika3781]

berarti saldomu minimal 1jt 20k bg? biar bisa dapat 2 gpc harga 1 jt

[@sidikridwan]

Bagaimana cara menentukan fields seperti saldo pada contoh ini apakah field itu adalah data yang akan di update( data yang bergerak) atau ada kriteria tersendiri? Makasih

[@ProgrammerZamanNow]

biasanya data yang bergerak nya

[@Danny-gv3tu]

race condition gini apakah bisa disolve dengan event-driven architecture? jadi tiap ada transaksi / permintaan checkout, kita insert ke tabel transaction, tapi tandai sebagai "belum beres checkout", lalu publish event untuk lakukan update saldo sebanyak +/- nilai transaksi, kalau berhasil, baru tandai transaksinya "beres checkout"

[@dewigesrek5651]

kyknya pake event driven pun masih bisa bro kena race

[@pramusintokhanif5979]

pakai event driven masih bisa kena dan karena saya sndri mengalami

[@indra_5629]

Berarti ini implementasi nya sama juga untuk stok gitu ya bang?

[@ProgrammerZamanNow]

betul

[@juditnugroho4306]

kalau db slave laging apa kalau pakai locking db itu bisa ya mas? Atau harus ada cara lain?

[@absormu929]

pake SELECT FOR UPDATE gimana mas?

[@ProgrammerZamanNow]

udah saya ajarkan di kelas MySQL

[@ryaniseverywhere]

ACID principles

[@umardev500]

RC di golang tinggal pasangin mutex

[@helhel5516]

Bagaimana jika locking nya menggunakan redis pak? apakah bisa juga?

[@nurcahyaari]

bantu jawab, bisa. saya biasanya lockingnya pakai distribtued lock punya Redis

[@trisna_cb]

Mas mau tanya lagi, kalo cara nanganin transaksi yang pending gimana? Misalkan kita API ke aplikasi aplikasi B (misal Payment Gateway), dan di kita dicatat sebagai saldo. Kita ga tahu aplikasi B akan mengirimkan status berhasil atau gagal. Dan kadang kalo transaksi expired si aplikasi B nya ga ngirim status apapun

[@Lukmandst]

mungkin bisa dihandler dari aplikasi a sendiri, misal expired dari b itu 30 menit. Jadi dari aplikasi a kalau ngga dapet feedback dari aplikasi b lebih dari 30 menit bakal otomatis update status jadi expired

[@guseggster]

sorry oot, itu app yg dipake gambar apa ya namanya?

[@hafidzfirman3260]

canva bang, pilih template papan tulis

[@joshuamartua9214]

GELOOO daging

[@qoisdzulfikarnugroho8357]

ini apa sama dengan deadlock ya? apa beda?

[@jshadinata]

berbeda. race condition ini efeknya inconsistency data solusinya: pakai transaction / lock tapi transaction / lock dapat menyebabkan deadlock. biasanya aplikasi yg trafficnya besar yg mengalami deadlock.

[@achyarca]

logic simple tapi mahal...

[@GusMiftah-i8u]

link a boss

[@invitationforyouu]

Ahha gue punya ide jahat 🗿

[@arifsubarkah9569]

Pas banget, lg nemuin bug ini kmaren. Di production pula wkwk. Cuman untuk data stok barang.

[@dlandsvolka4046]

Terima kasih.