The concepts of locking, blocking, and deadlocking are simple concepts on the surface, with quite a bit of complexity beneath the surface in the details. But as a parent of two small children, these concepts are modelled on a regular basis.
Locking:
First, the query requests a lock on a resource. So my son grabs a toy to play with. He has acquired a lock on that toy, a marker of sorts saying "I'm playing with this right now". I won't painfully try to thresh out the details of isolation levels and shared vs. exclusive locks as that would basically cause an already taxed analogy to implode.
Blocking:
Then my daughter looks at her brother's toy and thinks, I'd like to play with that toy. Too bad...a lock has been issued, and your request to play with that toy is denied. Blocking may end if my son lays the toy aside, thus releasing the lock on the toy.
Deadlocking:
While my son still has a "lock" held on the toy, and is blocking my daughter's request for it, my daughter picks up another toy, holding a lock on that item now. Then my son decides he wants that toy, too, and requests it. We have both kids, each holding a lock on a toy and blocking the other's request for it, wanting the other's toy. Neither will relinquish the toy they have until they get the other toy and can finish their playing. Deadlocking is this sort of stalemate that happens in the database/playroom where two queries get trapped in a kind of ill-fated interdependency, and the database engine/parents have to step in and choose a "deadlock victim" that has their query cancelled so at least one of the two can be satisfied.
At my rate, if I keep on torturing analogies like this I shall be receiving letters from Amnesty International.
No comments:
Post a Comment