Bagaimana Race Condition Terjadi di Database?
Summary
TLDRThe script discusses the importance of handling race conditions in database management, especially in financial applications. It explains race conditions as scenarios where multiple processes update the same data simultaneously, potentially leading to inconsistencies. The presenter illustrates the dangers of unaddressed race conditions using an e-wallet example and outlines methods to manage them, such as using database transactions and locks in SQL databases or conditional updates in NoSQL databases to ensure data consistency and prevent errors in financial transactions.
Takeaways
- 😀 The script discusses the importance of handling race conditions, especially in database management, as it is a common topic in interviews and a critical aspect of application development.
- 🏁 Race conditions occur when multiple processes attempt to update the same data simultaneously, leading to unpredictable outcomes.
- ⚠️ Poorly managed race conditions can be dangerous, particularly in financial or transactional applications where consistency and accuracy are crucial.
- 💡 The script provides a hypothetical scenario where a user named Eko with a balance of 1000 tries to make purchases, illustrating how race conditions can lead to incorrect balance updates.
- 🔐 To handle race conditions, the script suggests using database transactions and locking mechanisms to ensure that updates are processed sequentially and consistently.
- 🔗 The concept of 'locking' is introduced as a way to prevent other processes from accessing the same data until the current process has completed its transaction.
- 🛠️ The script explains how to implement transactional control and locking in SQL databases, which support these features, to manage race conditions effectively.
- 📚 It is emphasized that understanding how to handle race conditions is essential for developers, especially when working with relational databases that support transactions and locking.
- 💼 The script also touches on the challenges of managing race conditions in NoSQL databases that do not support traditional locking mechanisms, suggesting alternative approaches such as conditional updates.
- 💡 Finally, the script highlights the importance of this topic in job interviews, indicating that interviewers often ask about race conditions to assess a candidate's understanding of database management and application consistency.
Q & A
What is the main topic discussed in the script?
-The main topic discussed in the script is 'race condition', specifically in the context of database management and its implications in applications, particularly those related to finance or transactions.
Why is handling race conditions important in database management?
-Handling race conditions is crucial in database management because if not properly managed, it can lead to data inconsistencies, especially in financial or transactional applications, which can be dangerous and lead to significant errors or losses.
What is an example scenario where a race condition could occur?
-A race condition could occur when multiple processes try to update the same data simultaneously without proper synchronization, such as multiple transactions attempting to update a user's balance in an e-wallet at the same time.
How can race conditions be dangerous in financial applications?
-Race conditions can be dangerous in financial applications because they might lead to incorrect updates of financial data, such as double withdrawals from an account, incorrect balance calculations, or other inconsistencies that can result in financial loss or fraud.
What is the role of database transactions in preventing race conditions?
-Database transactions play a critical role in preventing race conditions by ensuring that a set of operations are executed in an atomic manner, meaning either all operations succeed or none are applied, thus maintaining data integrity.
What is locking in the context of database management, and how does it help with race conditions?
-Locking in database management is a mechanism to ensure that when a process is reading or writing data, no other process can modify it until the lock is released. This helps prevent race conditions by serializing access to the data.
How can you simulate the handling of race conditions with database transactions and locking?
-You can simulate the handling of race conditions by starting a transaction, performing a select query with a lock (e.g., 'SELECT ... FOR UPDATE'), and then attempting to update the data. If another process tries to access the locked data, it will be forced to wait until the lock is released.
What is the alternative approach to handling race conditions in non-relational databases that do not support locking?
-In non-relational databases that do not support locking, you can handle race conditions by modifying update queries to include conditions that check the last known state of the data before updating, ensuring that only the intended data is updated.
How can you ensure that an update query in a non-relational database is only applied to the correct data?
-You can ensure that an update query is only applied to the correct data by including the expected last known values in the update condition, so the update only proceeds if the current data matches the expected values, preventing unintended updates.
Why is understanding race conditions important for developers, especially during interviews?
-Understanding race conditions is important for developers because it demonstrates knowledge of concurrency issues and data integrity in software development. Interviewers often ask about race conditions to assess a candidate's awareness of these critical concepts and their ability to design robust applications.
Outlines
🚦 Understanding Race Conditions in Databases
The paragraph introduces the concept of race conditions in the context of database management, particularly during the interview process. It emphasizes the importance of understanding how to handle race conditions, especially in financial or transactional applications. The speaker provides an example of a race condition where multiple processes attempt to update the same data simultaneously, leading to unpredictable outcomes. The paragraph highlights the dangers of not properly managing race conditions, such as in e-wallet applications, and sets the stage for a deeper discussion on how to handle such scenarios.
🛠 Simulating Race Conditions and Their Impact
This section delves into a hypothetical scenario where race conditions occur in an e-wallet application. The speaker simulates a situation where a user named Eko has a balance of 1000 units of currency and attempts to make purchases that could trigger race conditions if not handled correctly. The paragraph explains the process of validating transactions before updating the database to prevent issues. It also discusses the potential for double transactions and how failing to manage race conditions can lead to financial discrepancies and system instability.
🔐 Implementing Transactional Control and Locking
The speaker discusses methods to handle race conditions in relational databases using transactions and locking mechanisms. The paragraph explains the importance of using database transactions to ensure that a series of operations either complete successfully together or roll back entirely if one fails. It also covers the use of locks to prevent other processes from accessing the same data simultaneously, thus avoiding race conditions. The speaker suggests using 'SELECT FOR UPDATE' to lock data for an update, ensuring consistency and preventing other transactions from interfering until the first one is completed.
🚧 Handling Race Conditions Without Lock Support
This paragraph addresses the challenge of managing race conditions in databases that do not support locking, such as many NoSQL databases. The speaker recommends using a relational database for safety but acknowledges scenarios where NoSQL databases might be necessary. The paragraph suggests modifying update queries to include the last known balance as a condition for the update, ensuring that only the intended data is updated. This approach relies on the database's ability to process commands sequentially and check conditions before applying updates.
🛡 Ensuring Data Integrity with Conditional Updates
The final paragraph focuses on ensuring data integrity when updating records in databases that do not support transactions or locking. The speaker illustrates how to structure update queries to include conditions that match the last known state of the data. This method helps prevent updates from overwriting changes made by other concurrent transactions. The paragraph explains how to check the 'impacted rows' or the number of rows affected by an update to determine if the update was successful. It also discusses handling scenarios where updates fail due to race conditions and the importance of managing these situations at the application level.
Mindmap
Keywords
💡Race Condition
💡Database
💡Transaction
💡Locking
💡SQL
💡NoSQL
💡Consistency
💡Rollback
💡Concurrency
💡Financial Applications
💡E-wallet
Highlights
Responsion is a crucial topic that must be understood to handle database transactions properly.
Responsion, or race condition, occurs when multiple processes update the same data simultaneously.
Mishandling race conditions can be dangerous, especially in financial or transactional applications.
An example scenario involves updating a user's balance in a database where multiple transactions occur at once.
The importance of validation before updating the database is emphasized to prevent issues like double spending.
A simulation of a race condition in an e-wallet application is discussed to illustrate the potential dangers.
The concept of handling race conditions in relational databases using transactions and locking is introduced.
Transactions ensure that a series of database operations are treated as a single unit, which helps in maintaining consistency.
Locking mechanisms prevent other processes from accessing the same data simultaneously during an update.
The use of 'SELECT FOR UPDATE' is highlighted as a method to lock data for an update in SQL databases.
A detailed simulation of how locking works in practice to prevent race conditions is provided.
The necessity of understanding race conditions when learning database management is stressed.
The transcript discusses handling race conditions in non-relational databases that do not support locking.
An alternative method for non-relational databases involves updating queries with conditions based on the last known data state.
The concept of checking the impact of an update operation to ensure it affected the correct data row is explained.
The importance of understanding how to handle race conditions during interviews for database-related positions is highlighted.
A summary of best practices for managing race conditions in both SQL and NoSQL databases is provided.
Transcripts
condition itu adalah salah satu topik
yang banyak sekali ya ditanyakan kalau
teman-teman misalnya lagi proses
interview misalnya nah tapi bukan
berarti ketika banyak orang yang
menanyakan tentang responsion bukan
berarti itu semacam formalitas aja gitu
ya biar orang tahu nggak tapi justru
Kenapa banyak ditanyakan karena ini
adalah salah satu hal yang wajib Agar
kita tahu gimana caranya menangani
responsion ya terutama database Kenapa
karena kalau misalnya sampai kita tidak
bisa menangani hal ini Nah itu bisa
berbahaya Nah di sini nanti saya
jelaskan contoh ya terjadinya responsion
Kenapa sangat berbahaya dan nanti gimana
cara penanganannya Yuk kita bahas
Oke kita balik ke katanya ya Apa itu Res
condition jadi di sini ada katanya Res
condition nah udah jelas sebenarnya ya
responsion itu berarti kondisi balapan
Ya maksudnya apa sih oke maksudnya kayak
gini kalau misalnya kasusnya adalah di
database condition atau kondisi balapan
ini di mana gitu ya ada satu data
misalnya atau ada beberapa data misalnya
gitu ya mau di-update secara bersamaan
oleh lebih dari satu proses Biasanya
seperti itu Jadi ini adalah kondisi
balapan ya dimana beberapa proses
melakukan balapan untuk mengupdate data
yang kemungkinan sama ya jadi misalnya
kita punya data contoh yang paling
simpel centangnya misalnya kita punya
data a gitu ya Misalnya ini ada data a
gitu ya Nah di sini ada request misalnya
request 1 di sini request 2 di sini
request 3 di sini request 4 misalnya
kita bikin aplikasi entah itu web
aplikasi mobile dan lain-lain nah misal
44 nya ini mau mengupdate data yang sama
jadi ini berbarengan seperti itu
updatenya ke yang sama
nah ini adalah namanya kondisi race
condition ya jadi balapan beberapa
proses mengupdate data yang sama Nah
kenapa kita perlu bisa menghandle ini
karena kalau sampai kita salah menangani
hal seperti ini maka akan bisa sangat
berbahaya terutama kalau kita bikin
aplikasinya yang berhubungan dengan
finansial ya atau keuangan itu sangat
berbahaya kalau sampai kita tidak bisa
menangani responsion Oke nextnya kita
coba simulasikan gimana sih Kejadian
responsion ini dan kenapa sangat
berbahaya ya terutama kalau aplikasi
kita berhubungan dengan finansial
Oke kita udah tahu ya sekarang itu
banyak banget aplikasi World ya
contohnya misalnya ada gopay ada dana
ada Ovo dan lain-lain
nah aplikasi-aplikasi seperti itu pasti
sudah menghandle responsion ini dengan
baik kenapa Karena kalau sampai tidak
maka itu sangat berbahaya Oke kita akan
coba simulasikan gimana contoh
responsion terjadi Anggap saja kita
bikin e-wallet misalnya gitu ya atau
e-money tapi kita lupa implementasi
responsion oke
misal kita punya user misalnya atau
misalnya Eko gitu ya Eko saldonya
misalnya 1 juta
atau ya paling gampang 1000 deh ya nah
jadi database kita punya data Eko lalu
dia itu
saldonya 1000 oke lalu saya ingin
membeli barang
membeli barang misalnya harganya 500
atau 700 deh ya apa yang terjadi ya
pastikan kita akan coba ya select dulu
ya untuk validasi ya Biasanya kita akan
coba validasi dulu jadi tidak langsung
tiba-tiba di update database Kenapa
karena kita harus validasi dulu misalnya
Oh saldo tidak cukup dan lain-lain jadi
Biasanya kita akan si like dulu
si like ya kita dapat nih oh datanya Eko
saldonya ternyata 1000 nah sedangkan
kita mau belinya misalnya 700 dari sini
kita tahu ya Oke kalau ini masih boleh
boleh transaksi ketika transaksi Apa
yang dilakukan ya kita biasanya lakukan
update
update misalnya Eco ya
set saldonya itu biasanya 1000 dikurangi
700 set 300 seperti ini nah Biasanya
kita lakukan seperti ini kalau
diperhatikan yang gak ada yang salah
dengan ini ya Nah karena memang biasanya
kita lakukan itu jadi kita validasi dulu
pastikan saldonya cukup Gitu ya kalau
udah cukup Oke kita akan langsung hapus
bukan hapus Sorry tidak ya atau kurangi
saldonya tadinya 1000 kita kurangi 700
Jadi 300 dari sini mungkin kita oke
nggak ada masalah aplikasi kita sampai
tiba-tiba ada kejadian orang yang
ngelakuin double purchase
dia belanja dua kali tapi di dedaknya
satu kali gitu ya Nah kenapa ini
kejadian Oke kasusnya adalah berarti
aplikasi kita tidak bisa menghandle
responsion dengan baik Jadi kalau
requestnya cuma satu-satu satu habis itu
satu lagi masuk satu lagi musik mungkin
itu kita bisa kenal dengan baik nah
gimana kalau Ternyata orangnya ngerti
gitu ya anggap aja dia pengen tester
atau lain-lain lah gitu ya dia Coba bius
fitur payment di e-wallet kita jadi dia
Coba Siapkan beberapa transaksi
contohnya 10 gitu ya lalu tiba-tiba dia
submit pada saat yang berbarengan nah
hal ini kalau kita proses seperti ini
bisa Kejadian karena responsion Oke kita
akan coba jadi misalnya dia udah nyiapin
anggap aja 3 barang barang yang pertama
adalah 800 barang yang kedua adalah 700
barang yang ketiga adalah 900 nah Apa
yang terjadi ketika dia submit
berbarengan query yang pertama kita
lakukan adalah query Silet ini ya Silet
di mana Eko saldonya berapa nih Nah
karena dia berbarengan
melakukan requestnya pada saat yang
berbarengan gitu ya maka ketika kita
melakukan Silet yang tadi semuanya dapat
saldonya 1000 ini 1000
ini 1000 ini juga 1000 Nah kenapa
seperti itu ya karena kan memang kita
melakukan Silet dulu untuk validasi ke
database gitu ya karena kalau tidak kita
validasi ke database ya bingung ya
masalah langsung di submit aja gitu ya
Nah kita pasti validasi dulu kita
ketika Si lag tiga-tiganya dapat 1000
Kenapa karena barang-barang semuanya
masuk Nah ketika dapat 1000 apa yang
terjadi berarti ini dianggap Oke valid
ya
karena masih di
atas
ini masih oke masuk ini juga sama masih
oke Dan ini juga sama masih oke nah
lihat kan dari sini kita udah kebayang
problemnya Apa akhirnya pada saat yang
bersamaan juga proses ini mengupdate
saldo jadi 200 gitu ya ini menjadi 300
ini menjadi 100 nah soal ini mana yang
menang ya nggak tahu ya nanti ya
untung-untungan aja yang menangnya
misalnya yang 300 gitu berarti yang 300
berarti di database kita yang ke record
itu mungkin cuma transaksi ini
dua transaksi ini tidak terikat Kenapa
karena
kejadiannya balapan dan ini yang menang
tapi dua ini juga tetap selesai
transaksinya ya dianggap sukses dianggap
sukses dianggap sukses nah ini sangat
berbahaya makanya kalau misalnya kita
bikin aplikasi yang berhubungan dengan
finansial ya atau transaksi lah
istilahnya kayak mungkin toko online
gitu ya maka ini perlu benar-benar
ditangani ya Untuk masalah responsion
ini contohnya sederhana kayak gini kalau
misalnya tiba-tiba bareng masuk
requestnya ketika kita validasi Oh
ternyata Saldonya masih cukup nih 1000
semua gitu ya jadi 33 requestnya masih
cukup akhirnya 33 itu dianggap sukses
Nah itu sangat berbahaya jadi ini
kejadian rest condition maka dari itu
tiap orang gitu ya ketika belajar
database harusnya benar-benar ngerti
gimana caranya menangani responden
Oke kita tahu ya di database itu ada dua
jenis saat ini kebanyakan ada yang
berbasis SQL atau relasional Anda juga
yang no sequel ya Nah kita bahas dulu
tentang cara menangani responsion di
yang database relasional ya atau
menggunakan SQL nah sebenarnya cara
kalau misalnya kita menangani responsion
di database relasional itu lumayan mudah
ya nah salah satunya yang paling penting
kita bisa proses semuanya harus
menggunakan database transaksional
namanya dan yang kedua adalah
menggunakan locking jadi ini harus
digabung ya jadi harus menggunakan BB
transaction dan harus menggunakan lock
seperti ini Jadi ini dua hal yang bisa
kita lakukan Oke kita akan coba
simulasikan yang tadi lagi gitu ya tapi
kita akan Coba lakukan debit
transaksional dan juga lock ya Oke jadi
yang pertama tadi kan ada dua jenis
query ya Yang pertama adalah silex untuk
dapetin saldonya saat ini berapa yang
kedua itu adalah updatenya Nah
dua-duanya kita harus rape menggunakan
database transaksional Nah teman-teman
kalau tidak tahu silahkan Googling ya
harusnya sih kita beneran harus tahu ya
tentang database transaksional
sederhananya adalah
kalau misalnya kita melakukan beberapa
instruksi query misalnya maka akan
dianggap sukses kalau semuanya sukses
dan akan dianggap gagal kalau salah
satunya gagal jadi kalau salah satunya
gagal maka semuanya akan di rollback
istilahnya atau digagalkan Nah kita
pengen hal itu terjadi jadi kita akan
jalan misalnya
Bigen transaction gitu Ya
bikin transaction misalnya dan terakhir
misalnya commit
transaction oke
Nah di sini yang pertama kan tadi ya
select dulu dan yang kedua itu adalah
update nah ketika melakukan select Nah
di sini kita harus implementasi yang
namanya locking locking itu menjaga agar
nanti ketika ada orang yang melakukan
silex lagi ke data yang sama maka dia
diminta untuk berhenti jadi menunggu
istilahnya tuh nunggu dulu sampai orang
yang pertama kali atau proses yang
pertama kali sukses ya melakukan lock
itu selesai melakukan komit transaksi
Jadi kalau belum selesai melakukan
komentar saksi maka yang lain tidak
boleh mendapatkan datanya dari sini kita
bisa memastikan bahwa datanya akan
konsisten ya Jadi kalau misalnya
tiba-tiba ada tadi ada 3 request bareng
masuk maka salah satunya yang akan
diperbolehkan mendapatkan lock-nya
mendapatkan kuncinya nah artinya dua
yang tadi akan menunggu sampai yang
pertama sukses atau selesai komen nah
ketika misalnya selesai komit nah dia
akan diberikan kunci selanjutnya ke
proses yang selanjutnya Nah setelah
selesai baru yang ke-3 yang terakhir
dengan seperti ini dengan kita
implementasi lock akan memaksa prosesnya
yang tadinya bareng masuk gitu ya maka
akan dipaksa menjadi sekuensial satu
persatu jadi ngantri istilahnya
Jadi yang pertama kita select
kalau misalnya di beberapa database
biasanya untuk locking di belakangnya
kalau misalnya select yang tadi ya data
Eko nanti di belakangnya di kita kasih
perintah lock Biasanya sih beberapa
database pakainya for misalnya update
jadi ini di lock kita udah tahu kalau
data ini akan di lock data Eco ini dan
di locknya itu untuk di-update kalau
datanya di lock for update artinya
Ketika nanti ada orang lain yang
melakukan si lag lagi ke data Eko maka
dia akan diminta menunggu Kenapa karena
yang ini itu akan melakukan update ada
juga si likenya for share ya kalau for
share itu cuma untuk di select aja nggak
akan di update seperti itu Nah setelah
itu setelah kita Silet ini ya sama di
sini tinggal update
update yang econya yang set saldonya
berapa gitu ya yang baru Nah dengan kita
menggunakan database Excel ini Oke
sekarang kita simulasikan lagi
simulasikan ada 3 request ya tadi
request yang pertama itu 800 produknya
habis itu yang 700 habis itu yang 900 ya
Oke ketika tiga-tiganya masuk lalu
tiga-tiganya akan start transaction ya
Nah Star transactionnya bareng start
trx Misalnya ini semuanya barang ya
tiga-tiganya Oke tapi perintah
selanjutnya itu adalah Silet ke database
gitu ya tapi menggunakan lock jadi
select Eco misalnya datanya yang for
update ya artinya Apa artinya kalau 33
ini melakukan hal yang sama maka si
database hanya akan memilih satu saja
yang diperbolehkan Nah siapa yang
diperbolehkannya kita nggak tahu ya
Tergantung ya kalau beneran milih
second-nya sama banget gitu ya ya paling
mungkin databasenya pilih salah satu
tapi kalau beda dikit ya paling ya yang
paling pertama aja yang duluan gitu ya
anggap aja misalnya yang pertama adalah
yang 900 itu jadi ini yang dapat 1000
ini apa ya Ini nunggu White
ini juga White
jadi nunggu dia nggak dapet saldo 1000
nya Nah setelah itu kan ini update ya
Nah ketika update jadi saldonya berapa
sekarang 100 setelah 100 ini komit ini
sorry tadinya saldonya 1000 berubah jadi
100 ini
setelah komet selesai Berarti kan
saldonya 100 Nah akhirnya locknya sudah
dilepas jadi di sini locknya dilepas
gitu ya selesai Nah selanjutnya adalah
akan diberikan locknya ke 2 Proses ini
nah tapi karena databasenya sudah jadi
100 ketika contohnya lock-nya sekarang
dikasihkan ke proses yang kedua ini di
sini dapatnya 100 saldonya sudah tidak
lagi 1000 karena di sini sudah di lock
dan di sini suruh nunggu Nah karena
saldonya 1000 maka ini otomatis di
batalin ya transaksinya
karena tidak lgble ya karena beli
barangnya 700 lalu akinya locknya
dilepas lagi akinya dikasih ke sini
dikasih ke sini saldonya tetap 100
select pertama jadi di sini kita udah
tahu kalau ini udah nggak lgble lagi nah
jadi dengan seperti ini kita bisa
menangani Rose condition dengan baik
Jadi kalau ada tiga Proses yang masuk Ya
udah yang pertama dulu gitu ya kalau
misalnya Saldonya masih oke ya baru
nanti dia di sukses yang kedua Tapi
kalau dari yang kedua udah tidak Oke ya
udah gagal ketika tidak Oke ya udah
gagal seperti itu Nah jadi ini
penanganan responsion kalau teman-teman
menggunakan database relasional ya yang
mendukung transaksional dan juga locking
Jadi kalau databasenya mungkin pakai
tetap pakai SQL misalnya tapi tidak
mendukung ini ya nggak bisa contohnya
mungkin Cassandra Cassandra kan pakai
hampir mirip kayak SQL juga tapi dia
nggak ada database transional sama
lockingnya seperti itu Nah jadi seperti
ini yang handle untuk yang relasional ya
yang support transaction dan locking nah
pertanyaannya Gimana kalau database yang
kita gunakan tidak mendukung locking nah
gimana caranya Yuk kita bahas
oke yang terakhir kita bahas cara
menangani responsion di my SQL ya atau
sebenarnya kan prosesnya kan sama kayak
tadi ya yang pertama kita select dulu
yang kedua adalah update cuma
pertanyaannya sekarang ketika ngelakuin
silek kita nggak bisa looking karena
beberapa ya hampir Kebanyakan sih ya
hampir kebanyakan nosikuel itu tidak
support working gitu ya termasuk juga
database transaksional nah pertanyaannya
gimana nih kalau databasenya seperti ini
nah jujur sih sebenarnya saya kalau
misalnya ada kasus teman-teman yang
berhubungan dengan
proses-proses kayak kejadian seperti ini
itu memang rekomendasinya adalah
menggunakan database yang relasional Ya
karena memang lebih aman nah tapi kalau
misalnya memang ada kasus kita udah
terlanjur menggunakan database yang no
sequel kalau pindahnya itu ke
database-nya itu lumayan Limbad Gimana
caranya nih untuk menangani ini Oke
caranya sebenarnya kita bisa ubah query
update-nya Jadi yang pertama kita masih
tetap siletnya yang sama gitu ya mungkin
teman-teman kalau pakai database seperti
mongo dan lain-lain ya find ke
databasenya masih tetap sama gitu ya
Jadi yang pertama prosesnya masih tetap
sama jadi contohnya
Eko misalnya ya Nah di sini kan otomatis
dapat 1000 ya Misalnya yang tadi
saldonya misalnya nah yang kedua ketika
proses update
itu kan biasanya kita update misalnya
gitu ya
pakainya set gitu ya Misalnya saldonya
sama dengan saldo terakhirnya misalnya
300 gitu ya Nah biasanya kan ditambah
wear
misalnya user sama dengan Eco seperti
ini
Nah sekarang teman-teman tambahkan
kondisi updatenya Jangan cuma where user
sama dengan Eko tapi apa teman-teman
juga harus Sebutkan saldo terakhirnya
jadi saldo terakhirnya contohnya di sini
saldo sama dengan 1000
seperti ini
Nah dengan kita menyebutkan saldo
terakhirnya 1000 Maka kalau misalnya ada
yang mengupdate berbarengan walaupun
update itu berbarengan biasanya database
ya Secara low level dia akan eksekusinya
satu persatu gitu ya artinya Apa artinya
kalaupun di aplikasi kita tidak bisa
handle Res condition gitu ya karena
tidak bisa melakukan locking tapi
Minimal kita percayakan proses ininya
respondennya di level database jadi kita
kirim query tapi kita tambahkan harus
saldo terakhirnya berapa
nah kasusnya jadinya gimana oke jadinya
seperti ini kalau kita lakukan seperti
ini gitu ya querynya seperti ini Anggap
saja kita nggak bisa locking Oke kita
akan simulasikan yang tadi lagi
jadi
tadi ini kayaknya kebesaran kita pakai
yang ini
Oke jadi misalnya tadi yang pertama itu
800 ya
terus 700 terus 900 Oke select yang
pertama udah pasti nih kita nggak bisa
locking jadi semuanya pasti dapat 1000
jadi ini dapat 1000
ini juga dapat 1000 ini juga dapat 1000
tapi kita bisa jaga di proses update-nya
nah ketika melakukan update
Kita kan nggak tahu ya Siapa yang duluan
dieksekusi oleh databasenya gitu ya tapi
yang penting ketika kita melakukan
update kita lakukan update seperti ini
jadi di sini proses updatenya itu kita
update Kalau yang ini ya kita kan 800
Sorry 1000 dikurangi 800 berarti 200 ya
jadi di sini set 200 saldonya
di mana usernya Eko
dan juga saldonya 1000
ini juga sama
set 3
00 usernya Eco saldonya 1000 ini juga
sama set 100 dimana usernya Eko saldonya
adalah 1000 nah ketika kita kirim
perintah ini 3 tidak tampil sebenarnya
karena dia mengupdate record yang sama
dia akan di handle satu persatu
sebenarnya nah pertanyaannya siapa yang
duluan ya kita nggak tahu ya Tergantung
databasenya suka-suka database mau
update yang mana Oke kita ya pura-pura
aja misalnya yang duluan itu yang ini
misalnya
ketika ini dilakukan perintahnya
kondisinya berarti saldonya berubah ya
Jadi 300 nah
jadi di sini saldo database sekarang 300
karena ini yang duluan
dan kondisinya pun sudah benar ya
usernya Eko dan ininya 100 ya
kita contreng dulu di sini nah jadi
kondisi ekornya benar dan ini kondisi
ininya benar Oke Berarti sekarang saldo
di database adalah 300 Oke ketika
misalnya sekarang yang kedua yang
dieksekusi ini gitu ya
set 200 ini otomatis tidak jadi query
update-nya itu diterima oleh database
tapi nanti Biasanya kita akan bisa dapat
impacted row impact with adalah berapa
banyak row yang ke-update dari proses
perintah update ini kalau di sini itu
kita biasanya dapat satu ya jadi di sini
dapat satu
karena memang iya match ke satu data
yaitu yang usernya Eko dan saldonya 1000
nah tapi yang query ini ini mungkin
ketika diupdate sukses jadi tidak ada
error ya kalau di yang sebelumnya kan
bisa error ya atau di rollback
transaksinya Tapi kalau ini tidak error
tetap diterima jadi mirip kayak
teman-teman dilihat data ke database
tapi datanya salah gitu ya tetep
diterima querynya tapi nanti impacted
rownya ada berapa gitu ya contohnya 0
nah ini
ketika dia set 200 usernya Eko udah
pasti ada user Eko tapi karena dia kirim
parameter juga dimana saldonya harus
1000 nah ini tidak dapat tidak database
karena saldo databasenya adalah 300 jadi
yang ini ketika dieksekusi maka impact
tutorialnya adalah kosong
Nah dari sini kita tahu kalau kosong dia
gagal jadi nanti kita handle di aplikasi
kita Oke ketika kita update ternyata
yang impact totronnya itu kosong itu
berarti gagal jadi kita bilang ke
usernya kalau transaksi anda gagal
seperti itu Nah selanjutnya kan
dipindahkan ke sini misalnya nah ketika
di sini juga sama gitu ya usernya Eko
dapat Tapi saldonya 1000 nggak dapat
karena saldo terakhir sekarang 300 jadi
ini impact to draw-nya akan nol juga nah
seperti ini dengan begitu otomatis ini
akan digagalkan jadi teman-teman bisa
gagalkan di level aplikasi ini
digagalkan ini juga digagalkan jadi yang
sukses itu cuma yang ini aja gitu ya
nah seperti ini Jadi ini kalau
teman-teman mau nangani responsionnya
yang di level yang bukan no SQL ya seri
yang bukan relasional database jadi di
database yang no sequel jadi bisa
teman-teman ubah si querynya jadi
querynya itu ditambahkan statement
terakhir istilahnya Jadi kalau saldo ya
saldo terakhir kalau misalnya misalnya
kalau Oh ada loyalty Point ya loyal
typoin terakhir sebelum di-update dan
lain-lain dengan ini bisa memastikan
bahwa ketika kita update itu benar-benar
mengupdate data yang kita mau dan kalau
impact rownya seperti ini contohnya Ini
kosong ini kosong berarti kita tahu
kalau dia mengupdate data yang
sebelumnya sudah berubah dengan begitu
ya Otomatis kita bisa gagal kan atau
batalkan sih prosesnya Nah jadi seperti
ini beberapa cara untuk menangani Res
condition ya Nah ini teman-teman perlu
pahami dengan baik Kenapa karena sering
banget kalau diproses interview itu
ditanyain soal responsion kenapa Ya
karena memang ini sangat berbahaya kalau
kita tidak bisa menangani responsion
dengan baik
5.0 / 5 (0 votes)