Isolation, concurrency and lost updates
≈ 45 minIsolation, concurrency and lost updates
Concurrency occurs when more than one user or process reads and changes shared data at nearly the same time. Without control, two people can read the same available quantity, both decide to buy it and both write a result that assumes they were alone. A lost update is one visible consequence: a later write replaces an earlier change without incorporating it.
Isolation strategies include locks, version checks and database isolation levels. The right strategy balances correctness and availability. A version number can let an update succeed only if the record is still the version that was read; otherwise the caller reloads and decides again. This makes conflict visible instead of silently choosing a winner.
Worked reasoning. Two cashiers both read stock = 1. Cashier A sells one and writes 0. Cashier B then writes 0 based on the old read, but records a second sale. A transaction with a row lock or version check prevents the second sale from committing until it sees that stock changed.
Exam lens. Show the interleaving of reads and writes. A concurrency problem is often invisible until you place the two timelines side by side.
Which statement is the most defensible principle for Isolation, concurrency and lost updates?
Enter the key term for Isolation, concurrency and lost updates. Which transaction property controls how concurrent work is separated?
A database update includes WHERE id = 7 AND version = 4 but updates zero rows. What should the program infer?
Name the concise safeguard or principle that completes this lesson’s scenario: A database update includes WHERE id = 7 AND version = 4 but updates zero rows. What should the program infer?

