Practice the vocabulary of detecting a write conflict at commit time instead of locking upfront.
0 / 5 completed
1 / 5
At standup, a dev mentions letting a transaction proceed without locking anything, then checking at commit time whether another transaction modified the same data in the meantime, rejecting one if there's a conflict. What is this approach called?
Optimistic concurrency control, or OCC, lets a transaction proceed without locking anything, checking only at commit time whether another transaction modified the same data, and rejecting one if there's a genuine conflict. Pessimistic locking instead blocks every other transaction from touching the same data upfront, which can hurt throughput when conflicts are actually rare. This optimistic approach is what lets a system avoid unnecessary blocking under a workload where a real conflict is uncommon.
2 / 5
During a design review, the team wants every update to check and increment a row's version number, rejecting the update if the version doesn't match what was originally read. Which capability supports this?
A version-based compare-and-swap check on update verifies a row's version number still matches what was originally read, rejecting the update if it doesn't, which indicates another transaction modified that row in the meantime. Updating every row unconditionally with no version check risks silently overwriting a change made by another transaction. This compare-and-swap check is the concrete mechanism that makes optimistic concurrency control actually detect a real conflict.
3 / 5
In a code review, a dev notices the application includes retry logic that re-reads and re-applies a rejected update, since OCC causes a genuine conflict to be rejected rather than silently blocked and resolved automatically. What does this represent?
Retry logic handling a rejected update re-reads and re-applies the change after a detected conflict, since OCC rejects a genuine conflict outright rather than silently blocking and resolving it automatically the way a lock would. Rejecting a conflicting update with no retry logic discards the user's intended change without ever actually applying it. This retry handling is a necessary companion to optimistic concurrency control, since a rejection on its own isn't a complete solution.
4 / 5
An incident report shows two concurrent updates to the same record both succeeded and one silently overwrote the other's change, because the version check that OCC depends on hadn't actually been implemented on that particular write path. What practice would prevent this?
Implementing the version-based compare-and-swap check on every write path ensures a genuine conflict between two concurrent updates is actually detected and one of them rejected. Allowing every update to succeed unconditionally, with no version check anywhere, is exactly what let one update silently overwrite the other in this incident. This check has to be implemented consistently everywhere OCC is relied upon, or its protection is only partial.
5 / 5
During a PR review, a teammate asks why the team uses optimistic concurrency control instead of pessimistic locking for updating a frequently read but rarely conflicting record. What is the reasoning?
OCC avoids the lock contention pessimistic locking would introduce under a workload where a genuine conflict is rare, since most transactions never actually collide with another one touching the same record. The cost is needing an explicit retry the rare time a real conflict does occur, since OCC rejects rather than blocks. The tradeoff shifts depending on how frequently a real conflict actually happens in the specific workload.
What does the "Optimistic Concurrency Control Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to optimistic concurrency control vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.