A reporting session has been waiting for four minutes on a row that another session updated but has not yet committed. No error has been raised, and the waiting session resumes as soon as the other session commits. A colleague calls this a deadlock. Which statement is accurate?

Blocking occurs when one session holds a lock that another session needs; the second session waits until the first commits or rolls back, then proceeds. It can last a long time if the holding transaction stays open, but it resolves itself as soon as the lock is released, and no error is raised unless a lock timeout or command timeout is reached. A deadlock is different: two or more sessions each wait on locks held by the others, forming a cycle in which none can proceed. The engine detects the cycle and rolls back one participant, the deadlock victim, returning an error to that session. The scenario, a one-directional wait that ended when the holder committed, is blocking. Classifying any long wait as a deadlock is incorrect; duration is not the criterion, the presence of a cycle is. Saying a deadlock leaves both sessions waiting until an administrator intervenes describes the opposite of how engines behave, since deadlock detection resolves cycles automatically. Claiming blocking only occurs across databases is wrong; blocking most often happens between sessions working on the same tables in the same database. Exam caveat: long blocking chains and deadlocks are both monitored, but they have different fixes; blocking usually calls for shorter transactions or better indexing, deadlocks for consistent access order. Operational check: inspect current sessions and their wait resources, identify the head of the blocking chain, and review why its transaction remains open.