Bagaimana Race Condition Terjadi di Database?

Summary

The 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

00:00

🚦 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.

05:00

🛠 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.

10:01

🔐 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.

15:03

🚧 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.

20:03

🛡 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.

Keywords

💡Race Condition

A race condition is a situation in software or a system where the output is dependent on the sequence or timing of other uncontrollable events. It becomes a critical issue in concurrent systems, such as multi-threaded applications or databases, where two or more processes or threads access shared resources and attempt to change them at the same time. In the script, the speaker explains that race conditions can be very dangerous, especially in financial applications, as they can lead to incorrect data handling and potential loss, such as double spending in an e-wallet application.

💡Database

A database is an organized collection of data, generally stored and accessed electronically from a computer system. The speaker in the script uses the term to discuss the importance of handling race conditions in database management systems, particularly when multiple processes try to update the same data simultaneously. The correct handling of such situations is crucial to maintain data integrity and prevent issues like double transactions.

💡Transaction

In the context of the script, a transaction refers to a series of operations performed as a single unit of work in a database. The script emphasizes the importance of using transactional databases to handle race conditions. Transactions ensure that a series of operations either all occur successfully or are rolled back in case of an error, maintaining the consistency and reliability of the database.

💡Locking

Locking in databases is a mechanism used to prevent race conditions by ensuring that when one process is accessing a particular data item, no other process can modify it. The script explains how implementing locks can help manage concurrent access to data, ensuring that updates are made in a controlled and sequential manner, thus preventing data inconsistencies that could arise from simultaneous updates.

💡SQL

SQL (Structured Query Language) is a standard language for managing and manipulating relational databases. The script mentions SQL in the context of using transactional control and locking mechanisms to handle race conditions. SQL databases that support transactions and locking are recommended for applications that require high data integrity and concurrency control.

💡NoSQL

NoSQL refers to a category of database management systems that do not adhere to the traditional relational database model. The script discusses the challenges of handling race conditions in NoSQL databases, which often do not support the same level of transactional control and locking mechanisms as SQL databases. The speaker suggests that for applications requiring strict concurrency control, it is advisable to use relational databases that support these features.

💡Consistency

Consistency in databases refers to the property of a system where all data remains accurate and consistent over time, even in the face of concurrent operations. The script emphasizes the importance of maintaining consistency to prevent errors such as double spending or incorrect data updates, which can occur due to race conditions.

💡Rollback

A rollback in database management systems is the process of undoing a series of actions or transactions that were previously executed. The script mentions rollbacks in the context of database transactions, where if one part of a transaction fails, the entire transaction can be rolled back to maintain data integrity and prevent partial updates that could result from race conditions.

💡Concurrency

Concurrency in computing refers to the ability of a system to handle multiple processes or tasks simultaneously. The script discusses concurrency in the context of database operations, where multiple users or processes might attempt to access and modify the same data at the same time, potentially leading to race conditions if not properly managed.

💡Financial Applications

Financial applications are software systems that deal with monetary transactions and require high levels of data accuracy and security. The script highlights the importance of handling race conditions in financial applications, as failures in these systems can lead to significant financial errors and losses, such as incorrect transactions or double payments.

💡E-wallet

An e-wallet, as mentioned in the script, is a digital platform that allows users to store, send, and receive monetary value electronically. The script uses the example of an e-wallet to illustrate the dangers of race conditions, where simultaneous transactions could lead to incorrect balance updates and financial discrepancies if not properly managed.

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