Build fluency in the vocabulary of taking an actual lock on a row before any other transaction can touch it.
0 / 5 completed
1 / 5
At standup, a dev mentions a database transaction taking an actual lock on a row the moment it reads it, so no other transaction can read or write that same row until the lock is released. What is this concurrency-control strategy called?
Pessimistic locking takes an actual lock on a row the moment a transaction reads it, blocking any other transaction from reading or writing that same row until the first transaction releases the lock, which guarantees no conflicting concurrent update can slip in during that window. Optimistic locking instead lets transactions proceed without ever blocking and only checks for a conflict at write time via a version number, retrying if a mismatch is found. This upfront, block-first approach is exactly what "pessimistic" refers to, assuming a conflict is likely enough that it's worth preventing outright rather than detecting after the fact.
2 / 5
During a design review, the team picks pessimistic locking specifically for a workload where conflicting concurrent updates to the same row are expected to be common. Which capability does this choice provide?
Choosing pessimistic locking for a high-conflict workload provides avoiding wasted retries under high contention, since the lock prevents a conflicting transaction from ever proceeding at all until the first one finishes, instead of letting many transactions race ahead only to fail and retry repeatedly under optimistic locking, wasting work on attempts that were doomed to conflict anyway. Optimistic locking's assume-no-conflict bet pays off poorly when conflicts are actually common, since retries pile up faster than they would under a lock that simply prevents the race in the first place. This is exactly why pessimistic locking is chosen specifically for workloads where real contention on the same row is known to be high.
3 / 5
In a code review, a dev notices a pessimistic-locking transaction holds its lock on a row for an unusually long time while it performs a slow, unrelated network call in the middle of the transaction. What does this represent?
This is a lock held far longer than necessary, since performing a slow, unrelated network call while still holding the row's lock blocks every other transaction that needs that same row for the entire duration of that unrelated operation, even though the lock was only ever meant to protect the row's own read-then-write sequence. A cache eviction policy is an unrelated concept about discarded cache entries. This is exactly the kind of contention-amplifying mistake a reviewer needs to catch, since pessimistic locking's cost scales directly with how long each lock is actually held, not just how many rows are locked.
4 / 5
An incident report shows a service's throughput collapsed under moderate load because a pessimistic-locking transaction held a row's lock open across a slow, unrelated network call, causing every other transaction needing that row to queue up and wait for the entire duration of that call. What practice would prevent this?
Restructuring the transaction so the lock is only held for the minimal window actually needed to read and write the row, and moving any slow, unrelated work like a network call outside that locked section entirely, is exactly the fix for the throughput collapse described in this incident. Continuing to hold the lock open across the slow call for its entire duration is exactly what caused every other transaction needing that row to queue up and wait. This minimal-lock-duration discipline is a standard requirement for using pessimistic locking safely, since the cost of a lock scales directly with how long it's actually held, not just how many rows it covers.
5 / 5
During a PR review, a teammate asks why the team is careful to minimize how long a pessimistic lock is held instead of just locking the row for the whole transaction regardless of what other work that transaction happens to do. What is the reasoning?
Every other transaction needing that same row has to wait for the entire duration the lock is actually held, so any unrelated slow work, like a network call or an expensive computation, performed while still holding the lock directly extends how long every other waiting transaction is forced to queue, even though that slow work has nothing to do with the row itself. Minimizing the lock's hold time to just the actual read-then-write sequence keeps that queuing delay as short as possible for everyone else. The tradeoff is that this often requires restructuring a transaction to do any unrelated work before acquiring the lock or after releasing it, rather than simply wrapping the entire transaction in one lock for convenience.
What does the "Pessimistic Locking Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to pessimistic locking 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.