Lock
Two requests decrement the last item concurrently. Lock the shared record so one proceeds and the other waits and rechecks.
Two requests decrement the last item concurrently. Lock the shared record so one proceeds and the other waits and rechecks.
The shared record has no access order.
Problem and key mechanism: Both requests can read stock 1 and decrement it, causing overselling; lock the shared inventory record so one request checks and updates while the other waits and then rechecks.
Verify the waiter rechecks: Concurrent testing yields one success, one out-of-stock result, and final stock 0. Cross-instance scope and deadlock still need handling.
A second scenario: clinic scheduling: When two staff members schedule the same clinic room and time slot, the lock should cover that shared slot. After the first releases it, the waiter rechecks so two appointments cannot occupy the same slot.
Lock the inventory check and update for the same shared record. Record owner, waiter, release, and timeout. Test two concurrent requests so only one succeeds and the waiter rechecks after acquiring the lock and returns out of stock. If the service has multiple instances, do not rely only on separate in-process locks.