When many users read and write the same data at the same time, a database needs a way to decide who may touch what, and when. Locking is the most common mechanism for making that decision. A shared (read) lock lets several transactions read the same item concurrently, while an exclusive (write) lock gives one transaction sole access so that no one else reads or modifies the item mid-change. Intent locks sit above these at coarser levels of the data hierarchy, signaling that a transaction holds or plans to hold locks further down so the engine can detect conflicts without inspecting every row.
Lock granularity is the second half of the picture: a lock can cover a single row, a page, a partition, or an entire table. Fine granularity allows more concurrency but costs memory and bookkeeping, so engines perform lock escalation, converting many fine-grained locks into one coarse lock once a threshold is crossed. That conversion protects the lock manager but can suddenly block other users. This is the central trade-off of the topic and of this course module: more locking means stronger data protection and fewer anomalies, while less locking means better throughput and more risk.
As you watch the videos below, keep three questions in mind. First, which lock modes are compatible with which others, and why does that compatibility matrix matter? Second, at what level of the data hierarchy is each lock being taken? Third, what happens when locks collide — blocking, waiting, or deadlock — and what does the database do about it? Connect what you see to the isolation levels and concurrency anomalies covered elsewhere in this module, since isolation levels are largely implemented through locking behavior.
This tutorial walks through the two-phase locking protocol, the classic rule set that governs how transactions acquire and release shared and exclusive locks. Based on its title and description, it explains how growing and shrinking phases of lock acquisition guarantee serializable schedules, and works through a concrete example schedule step by step.
It gives the formal foundation for shared and exclusive locks and shows precisely why lock mode compatibility produces correct, serializable execution — the theory that underlies everything else in this topic.
John McCormack explains locks, blocking, and deadlocks as they actually appear in SQL Server, distinguishing a normal lock from a block caused by waiting and from a true deadlock between transactions. Expect practical discussion of why these conditions arise in production workloads and how a DBA recognizes and responds to them.
It moves the concepts from theory into a real commercial engine, which is exactly where intent locks, granularity, and escalation have visible consequences, and the presenter is an experienced SQL Server practitioner.
This short overview ties transactions and locking together, covering how a transaction's boundaries determine how long locks are held and how that affects other users. It is positioned as a concise, no-filler IT skills lesson rather than a deep theoretical treatment.
It is a compact review that reinforces the link between transaction design and lock duration, which is the practical lever students adjust when balancing concurrency against data protection.
These videos support the module outcomes by showing the mechanism behind the concepts. The two-phase locking tutorial explains how shared and exclusive locks enforce serializability, which underpins the isolation component of ACID (MO1) and clarifies why certain isolation levels prevent certain anomalies such as dirty reads, non-repeatable reads, and lost updates (MO2). The SQL Server video on locks, blocks, and deadlocks demonstrates the real performance cost of strong locking, giving you concrete evidence to weigh when selecting an isolation level (MO3) and a direct view of deadlock detection and resolution that feeds into a mitigation plan involving timeouts and victim selection (MO5). Together, all three illustrate pessimistic concurrency control in action, which is the baseline you need in order to compare it meaningfully with optimistic and multiversion approaches (MO4).
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.