Lock Definition - Lock Concepts | OneNoughtOne

0/278

Database Management SystemsLock Concepts

Lock Concepts

LevelIntermediate

Duration60 mins

TopicLock Concepts

1 / 5

Lock Definition

The Guardian of Data Integrity

Imagine a busy bank on a Friday afternoon. Hundreds of transactions are occurring simultaneously: customers withdrawing cash, merchants processing payments, automated systems transferring funds. Now imagine if two tellers could modify the same account balance at the exact same instant, with no coordination between them. The result would be chaos—money appearing from thin air or vanishing without a trace.

Locks are the solution to this chaos. They are the fundamental mechanism that prevents concurrent transactions from corrupting each other's work. Every time you swipe a credit card, every time a database query updates a row, every time an online order is placed—locks are working silently in the background, ensuring that concurrent operations don't step on each other's toes.

In this page, we dive deep into the concept of database locks: what they are, why they exist, and how they form the bedrock of transaction management in every serious database system.

What You Will Learn

By the end of this page, you will understand the formal definition of locks, their fundamental purpose in database systems, the lifecycle of a lock from acquisition to release, and how locks interact with the transaction model we explored in previous chapters.

The Fundamental Problem: Concurrent Access

Before we define locks, we must understand precisely what problem they solve. Consider a database system serving thousands of concurrent users. Each user's transaction needs to read and write data items. Without any coordination mechanism, several catastrophic scenarios can occur:

Concurrency Anomalies Without Locks

•Lost Updates — Transaction T₁ reads a value, T₂ reads the same value, both modify it, and one update overwrites the other. Money literally disappears from the system.
•Dirty Reads — Transaction T₁ reads data modified by T₂ before T₂ commits. If T₂ aborts, T₁ has based its decisions on data that never officially existed.
•Non-Repeatable Reads — Transaction T₁ reads the same data item twice and gets different values because T₂ modified it between reads.
•Phantom Reads — Transaction T₁ executes a query twice, and the second execution returns rows that didn't exist during the first execution.

These problems aren't theoretical curiosities—they represent real data corruption that can cost businesses millions of dollars and erode user trust. The fundamental insight is that uncontrolled concurrent access to shared data is inherently dangerous.

The core challenge: How do we allow multiple transactions to access the database simultaneously (for performance and throughput) while preventing them from interfering with each other (for correctness)?

This is the concurrency control problem, and locks are the most widely-deployed solution.

The Serialization Requirement

Recall from our study of serializability that a schedule is correct if it is equivalent to some serial execution of transactions. Locks are a mechanism to ensure that even when transactions execute concurrently, their operations are interleaved in a way that produces a serializable schedule.

Formal Definition of a Lock

A lock is a synchronization mechanism that controls access to a data item by concurrent transactions. More formally:

A lock is a variable associated with a data item that describes the state of the item with respect to possible operations that can be applied to it.

Let's break this definition into its constituent parts:

Components of the Lock Definition

•Synchronization Mechanism — Locks coordinate the actions of multiple transactions, ensuring they don't conflict. They are primitives for achieving mutual exclusion and ordered access.
•Variable Associated with a Data Item — Each lockable item (row, page, table, etc.) has a corresponding lock variable. The lock doesn't contain the data; it guards access to it.
•State Description — The lock variable encodes whether the item is currently being accessed, by whom, and what kind of access is occurring (reading or writing).
•Possible Operations — Locks determine what operations can proceed. A locked item may allow some operations (e.g., additional reads) while blocking others (e.g., writes).

The Lock Abstraction:

Conceptually, a lock works like a checkout system in a library. Before a patron (transaction) can take a book (data item) home, they must check it out at the desk. The library tracks who has which book, preventing two patrons from taking the same book simultaneously. When returned (lock released), the book becomes available again.

Lock Conceptual Mapping
Library Concept	Lock Concept	Purpose
Book	Data Item	The resource being accessed
Patron	Transaction	The entity requesting access
Checkout Desk	Lock Manager	Coordinates access requests
Library Card	Transaction ID	Identifies who holds the lock
Due Date	Lock Duration	Period lock is held
Return	Unlock/Release	Relinquishing access rights

Why "Lock" and Not "Permission"?

The term 'lock' emphasizes exclusivity and control. Unlike permissions that can be freely granted to many parties, locks enforce restrictions. When a transaction holds a certain lock, other transactions are explicitly prevented from taking conflicting locks. The metaphor of a physical lock—which blocks others from entry—accurately captures this mechanism.

Lock Operations

Transactions interact with locks through a well-defined set of operations. These operations are atomic—they either complete fully or not at all—and are managed by the Lock Manager, a component of the database system.

The fundamental lock operations are:

Primary Lock Operations

•lock(X) or acquire(X) — Request a lock on data item X. If the lock is available (compatible with existing locks), it is granted immediately. If not, the requesting transaction is placed in a wait queue.
•unlock(X) or release(X) — Release the lock held on data item X. This allows waiting transactions to potentially acquire the lock.
•upgrade(X) — Convert a weaker lock to a stronger lock (e.g., read lock to write lock) on the same data item.
•downgrade(X) — Convert a stronger lock to a weaker lock (e.g., write lock to read lock), potentially allowing more concurrency.

lock_operations.pseudo

Pseudocode

// Basic locking protocol for a transaction
TRANSACTION T1:
    BEGIN TRANSACTION
    
    // Request a lock before reading or writing
    lock(account_balance)      -- Acquire lock on data item
    
    // Now safe to access the data
    balance = READ(account_balance)
    balance = balance - 100
    WRITE(account_balance, balance)
    
    // Release lock when done
    unlock(account_balance)    -- Release lock
    
    COMMIT
 
// Lock Manager handles concurrent requests
LOCK_MANAGER:
    on lock_request(transaction_id, data_item, lock_type):
        if compatible(current_lock_on(data_item), lock_type):
            grant_lock(transaction_id, data_item, lock_type)
            return GRANTED
        else:
            add_to_wait_queue(transaction_id, data_item, lock_type)
            return WAITING
    
    on unlock_request(transaction_id, data_item):
        release_lock(transaction_id, data_item)
        wake_up_waiting_transactions(data_item)

Critical Properties of Lock Operations:

Atomicity: Lock acquisition and release are atomic operations. There's no intermediate state where a lock is "partially held."
Mutual Exclusion: Conflicting locks cannot be held simultaneously on the same data item.
Progress: If no transaction holds a conflicting lock, a lock request eventually succeeds.
Fairness: Waiting transactions are typically granted locks in some fair order (often FIFO) to prevent starvation.

Blocking and Waiting

When a transaction requests a lock that conflicts with an existing lock, it must wait. This waiting can block the transaction indefinitely if the holder never releases. Worse, if two transactions wait for each other's locks, a deadlock occurs. We'll explore deadlock handling in a later module.

The Lock Manager

The Lock Manager is a critical subsystem of the database engine responsible for maintaining lock state and processing lock requests. Understanding its architecture helps clarify how locks work in practice.

Lock Manager Responsibilities

•Maintaining the Lock Table — A data structure (typically a hash table) that maps each locked data item to its current lock state, holder(s), and waiting queue.
•Processing Lock Requests — When a transaction requests a lock, the lock manager checks compatibility and either grants immediately or enqueues the request.
•Processing Unlock Requests — When a lock is released, the lock manager updates the lock table and wakes up waiting transactions that can now proceed.
•Deadlock Detection/Prevention — The lock manager may run algorithms to detect cycles in the wait-for graph or prevent deadlocks before they occur.
•Lock Escalation — When a transaction holds many fine-grained locks, the lock manager may escalate to a coarser lock to reduce overhead.

Converting Mermaid diagram...

The Lock Table Structure:

The lock table is typically organized as a hash table where the key is the identifier of the data item (e.g., table name + row ID). Each entry contains:

Lock Mode: Current lock type held (shared, exclusive, etc.)
Holder List: Transaction IDs currently holding the lock
Waiting Queue: Ordered list of transactions waiting for the lock
Lock Count: Number of shared locks (since multiple can coexist)

lock_table_structure.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// Simplified Lock Table Entry Structure
interface LockTableEntry {
    dataItemId: string;           // Identifier of locked resource
    lockMode: 'UNLOCKED' | 'SHARED' | 'EXCLUSIVE';
    holders: Set<TransactionId>;  // Transactions currently holding lock
    waitQueue: Array<{
        transactionId: TransactionId;
        requestedMode: 'SHARED' | 'EXCLUSIVE';
        timestamp: Date;          // For FIFO ordering
    }>;
    sharedCount: number;          // Number of shared lock holders
}
 
// Lock Table as a Hash Map
class LockTable {
    private entries: Map<string, LockTableEntry> = new Map();
    
    getLockEntry(dataItemId: string): LockTableEntry {
        if (!this.entries.has(dataItemId)) {
            // Create new entry for unlocked item
            this.entries.set(dataItemId, {
                dataItemId,
                lockMode: 'UNLOCKED',
                holders: new Set(),
                waitQueue: [],
                sharedCount: 0
            });
        }
        return this.entries.get(dataItemId)!;
    }
    
    isCompatible(entry: LockTableEntry, requestedMode: string): boolean {
        if (entry.lockMode === 'UNLOCKED') return true;
        if (entry.lockMode === 'SHARED' && requestedMode === 'SHARED') return true;
        return false;  // EXCLUSIVE conflicts with everything
    }
}

Lock Manager Performance

The lock manager must be extremely fast since every data access goes through it. Modern lock managers use sophisticated techniques like lock-free data structures, partitioned lock tables, and adaptive spinning to minimize overhead.

Lock Lifecycle

Every lock goes through a well-defined lifecycle from creation to destruction. Understanding this lifecycle is crucial for reasoning about transaction behavior and diagnosing concurrency issues.

Converting Mermaid diagram...

Lock Lifecycle Phases

•Requested — The transaction calls lock(X). The lock manager receives the request and looks up X in the lock table.
•Waiting (optional) — If the lock conflicts with existing locks, the transaction enters a blocked state. It joins the wait queue and suspends execution.
•Granted — The lock manager grants the lock, either immediately or after waiting. The lock table is updated to reflect the new holder.
•Held — The transaction holds the lock and can safely access the data item. Other conflicting requests will be blocked.
•Released — The transaction calls unlock(X), commits, or aborts. The lock is removed from the lock table, and waiting transactions are woken up.

Duration of Lock Holding:

How long a transaction holds a lock depends on the locking protocol in use:

Short-Duration Locks: Acquired and released around individual operations. Maximizes concurrency but doesn't guarantee serializability.
Long-Duration Locks: Held for the entire transaction (until commit/abort). Used in Two-Phase Locking to guarantee serializability.
Lock-Duration Rules: Different lock types may have different duration rules. Read locks might be released early; write locks held until commit.

The choice of lock duration directly affects both correctness and performance.

Critical Rule: Never Forget to Release

If a transaction fails to release its locks (due to bugs, crashes, or hangs), those data items become permanently inaccessible to other transactions. This is why proper transaction management—including robust error handling and automatic lock release on abort—is essential.

Locks and Transaction Isolation

Locks are the primary mechanism for implementing transaction isolation levels. Each isolation level represents a different tradeoff between concurrency (performance) and consistency (correctness), achieved by varying lock behavior.

Isolation Levels and Locking Behavior
Isolation Level	Read Lock Behavior	Write Lock Behavior	Anomalies Prevented
Read Uncommitted	No read locks acquired	Write locks held to commit	None (allows dirty reads)
Read Committed	Short read locks (release after read)	Write locks held to commit	Dirty reads prevented
Repeatable Read	Long read locks (held to commit)	Write locks held to commit	Dirty reads, unrepeatable reads
Serializable	Long read locks + range locks	Write locks + range locks	All anomalies (including phantoms)

The Relationship Between Locks and ACID:

Locks primarily enforce the Isolation property of ACID:

Atomicity: Ensured by transaction logs and rollback mechanisms (not directly by locks)
Consistency: Application-level constraints + isolation working together
Isolation: Directly enforced by locking protocols
Durability: Ensured by write-ahead logging and recovery (not directly by locks)

However, locks interact with atomicity: if a transaction aborts, it must release all its locks to allow other transactions to proceed.

What Locks Guarantee

•Mutual exclusion for conflicting operations
•Prevention of lost updates
•Controlled access to shared data
•Foundation for serializability
•Predictable transaction behavior

What Locks Don't Guarantee

•Deadlock freedom (must be handled separately)
•Optimal performance (locks reduce concurrency)
•Logical correctness of transactions
•Recovery from failures
•Protection against application bugs

Locks Are Necessary But Not Sufficient

While locks are essential for concurrency control, they don't solve all problems. A well-designed database system combines locks with other mechanisms: logging for durability, validation for consistency, and deadlock handling for liveness. Think of locks as one pillar of a multi-pillared architecture.

Binary Locks: The Simplest Model

The simplest form of locking is the binary lock, which has only two states: locked and unlocked. A binary lock provides mutual exclusion—only one transaction can hold the lock at any time.

binary_lock.pseudo

Pseudocode

// Binary Lock Operations
LOCK(X):
    if LOCK_STATE(X) == UNLOCKED:
        LOCK_STATE(X) = LOCKED
        HOLDER(X) = current_transaction
        return GRANTED
    else:
        // Wait until X is unlocked
        wait until LOCK_STATE(X) == UNLOCKED
        LOCK_STATE(X) = LOCKED
        HOLDER(X) = current_transaction
        return GRANTED
 
UNLOCK(X):
    if HOLDER(X) == current_transaction:
        LOCK_STATE(X) = UNLOCKED
        HOLDER(X) = null
        signal any waiting transactions
    else:
        error "Cannot unlock: not the holder"
 
// Usage Rules:
// 1. A transaction must call LOCK(X) before any READ(X) or WRITE(X)
// 2. A transaction must call UNLOCK(X) after finishing with X
// 3. A transaction cannot lock an item it already holds
// 4. A transaction cannot unlock an item it doesn't hold

Limitations of Binary Locks:

While simple, binary locks are overly restrictive. Consider two transactions that only want to read a data item:

T1: LOCK(X) → READ(X) → UNLOCK(X)
T2: LOCK(X) → READ(X) → UNLOCK(X)

With binary locks, T2 must wait for T1 to finish, even though two readers can safely access data simultaneously. This unnecessary blocking reduces concurrency and system throughput.

To address this, we introduce multiple lock modes—the subject of our next pages on Shared Locks and Exclusive Locks.

Binary Locks in Practice

Binary locks are rarely used in real database systems due to their concurrency limitations. However, they're valuable for understanding the fundamentals. Many non-database systems (like file locks or simple thread synchronization) do use binary locks because their access patterns don't distinguish between reads and writes.

Summary: The Foundation of Concurrency Control

We've established the foundational understanding of locks in database systems. Let's consolidate the key concepts:

Key Takeaways

•Locks solve concurrency conflicts — They prevent anomalies like lost updates, dirty reads, and non-repeatable reads by controlling access to shared data.
•A lock is a state variable — Associated with each data item, describing who can access it and how.
•The Lock Manager coordinates access — It maintains the lock table, processes requests, and manages waiting queues.
•Lock operations are atomic — lock(), unlock(), upgrade(), and downgrade() are indivisible operations.
•Locks have a lifecycle — From request through waiting, granting, holding, and release.
•Locks implement isolation — Different lock behaviors produce different isolation levels.
•Binary locks are simple but limiting — They don't distinguish between readers and writers.

What's Next:

Now that we understand what locks are and why they exist, we'll explore the two fundamental lock types used in all modern database systems:

Shared Locks (S): Allow multiple readers to access data concurrently
Exclusive Locks (X): Provide exclusive access for writers

These two lock modes, along with the compatibility rules between them, form the basis of practical concurrency control.

Page Complete

You now understand the fundamental concept of database locks: their purpose, definition, operations, lifecycle, and relationship to transaction isolation. In the next page, we'll dive into Shared Locks—the mechanism that enables concurrent readers without sacrificing consistency.

Database Management SystemsLock Concepts

Lock Concepts

LevelIntermediate

Duration60 mins

TopicLock Concepts

1 / 5

Lock Definition

The Guardian of Data Integrity

In this page, we dive deep into the concept of database locks: what they are, why they exist, and how they form the bedrock of transaction management in every serious database system.

What You Will Learn

The Fundamental Problem: Concurrent Access

Concurrency Anomalies Without Locks

•Lost Updates — Transaction T₁ reads a value, T₂ reads the same value, both modify it, and one update overwrites the other. Money literally disappears from the system.
•Dirty Reads — Transaction T₁ reads data modified by T₂ before T₂ commits. If T₂ aborts, T₁ has based its decisions on data that never officially existed.
•Non-Repeatable Reads — Transaction T₁ reads the same data item twice and gets different values because T₂ modified it between reads.
•Phantom Reads — Transaction T₁ executes a query twice, and the second execution returns rows that didn't exist during the first execution.

This is the concurrency control problem, and locks are the most widely-deployed solution.

The Serialization Requirement

Formal Definition of a Lock

A lock is a synchronization mechanism that controls access to a data item by concurrent transactions. More formally:

A lock is a variable associated with a data item that describes the state of the item with respect to possible operations that can be applied to it.

Let's break this definition into its constituent parts:

Components of the Lock Definition

•Synchronization Mechanism — Locks coordinate the actions of multiple transactions, ensuring they don't conflict. They are primitives for achieving mutual exclusion and ordered access.
•Variable Associated with a Data Item — Each lockable item (row, page, table, etc.) has a corresponding lock variable. The lock doesn't contain the data; it guards access to it.
•State Description — The lock variable encodes whether the item is currently being accessed, by whom, and what kind of access is occurring (reading or writing).
•Possible Operations — Locks determine what operations can proceed. A locked item may allow some operations (e.g., additional reads) while blocking others (e.g., writes).

The Lock Abstraction:

Lock Conceptual Mapping
Library Concept	Lock Concept	Purpose
Book	Data Item	The resource being accessed
Patron	Transaction	The entity requesting access
Checkout Desk	Lock Manager	Coordinates access requests
Library Card	Transaction ID	Identifies who holds the lock
Due Date	Lock Duration	Period lock is held
Return	Unlock/Release	Relinquishing access rights

Why "Lock" and Not "Permission"?

Lock Operations

The fundamental lock operations are:

Primary Lock Operations

•lock(X) or acquire(X) — Request a lock on data item X. If the lock is available (compatible with existing locks), it is granted immediately. If not, the requesting transaction is placed in a wait queue.
•unlock(X) or release(X) — Release the lock held on data item X. This allows waiting transactions to potentially acquire the lock.
•upgrade(X) — Convert a weaker lock to a stronger lock (e.g., read lock to write lock) on the same data item.
•downgrade(X) — Convert a stronger lock to a weaker lock (e.g., write lock to read lock), potentially allowing more concurrency.

lock_operations.pseudo

Pseudocode

// Basic locking protocol for a transaction
TRANSACTION T1:
    BEGIN TRANSACTION
    
    // Request a lock before reading or writing
    lock(account_balance)      -- Acquire lock on data item
    
    // Now safe to access the data
    balance = READ(account_balance)
    balance = balance - 100
    WRITE(account_balance, balance)
    
    // Release lock when done
    unlock(account_balance)    -- Release lock
    
    COMMIT
 
// Lock Manager handles concurrent requests
LOCK_MANAGER:
    on lock_request(transaction_id, data_item, lock_type):
        if compatible(current_lock_on(data_item), lock_type):
            grant_lock(transaction_id, data_item, lock_type)
            return GRANTED
        else:
            add_to_wait_queue(transaction_id, data_item, lock_type)
            return WAITING
    
    on unlock_request(transaction_id, data_item):
        release_lock(transaction_id, data_item)
        wake_up_waiting_transactions(data_item)

Critical Properties of Lock Operations:

Atomicity: Lock acquisition and release are atomic operations. There's no intermediate state where a lock is "partially held."
Mutual Exclusion: Conflicting locks cannot be held simultaneously on the same data item.
Progress: If no transaction holds a conflicting lock, a lock request eventually succeeds.
Fairness: Waiting transactions are typically granted locks in some fair order (often FIFO) to prevent starvation.

Blocking and Waiting

The Lock Manager

Lock Manager Responsibilities

•Maintaining the Lock Table — A data structure (typically a hash table) that maps each locked data item to its current lock state, holder(s), and waiting queue.
•Processing Lock Requests — When a transaction requests a lock, the lock manager checks compatibility and either grants immediately or enqueues the request.
•Processing Unlock Requests — When a lock is released, the lock manager updates the lock table and wakes up waiting transactions that can now proceed.
•Deadlock Detection/Prevention — The lock manager may run algorithms to detect cycles in the wait-for graph or prevent deadlocks before they occur.
•Lock Escalation — When a transaction holds many fine-grained locks, the lock manager may escalate to a coarser lock to reduce overhead.

Converting Mermaid diagram...

The Lock Table Structure:

The lock table is typically organized as a hash table where the key is the identifier of the data item (e.g., table name + row ID). Each entry contains:

Lock Mode: Current lock type held (shared, exclusive, etc.)
Holder List: Transaction IDs currently holding the lock
Waiting Queue: Ordered list of transactions waiting for the lock
Lock Count: Number of shared locks (since multiple can coexist)

lock_table_structure.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// Simplified Lock Table Entry Structure
interface LockTableEntry {
    dataItemId: string;           // Identifier of locked resource
    lockMode: 'UNLOCKED' | 'SHARED' | 'EXCLUSIVE';
    holders: Set<TransactionId>;  // Transactions currently holding lock
    waitQueue: Array<{
        transactionId: TransactionId;
        requestedMode: 'SHARED' | 'EXCLUSIVE';
        timestamp: Date;          // For FIFO ordering
    }>;
    sharedCount: number;          // Number of shared lock holders
}
 
// Lock Table as a Hash Map
class LockTable {
    private entries: Map<string, LockTableEntry> = new Map();
    
    getLockEntry(dataItemId: string): LockTableEntry {
        if (!this.entries.has(dataItemId)) {
            // Create new entry for unlocked item
            this.entries.set(dataItemId, {
                dataItemId,
                lockMode: 'UNLOCKED',
                holders: new Set(),
                waitQueue: [],
                sharedCount: 0
            });
        }
        return this.entries.get(dataItemId)!;
    }
    
    isCompatible(entry: LockTableEntry, requestedMode: string): boolean {
        if (entry.lockMode === 'UNLOCKED') return true;
        if (entry.lockMode === 'SHARED' && requestedMode === 'SHARED') return true;
        return false;  // EXCLUSIVE conflicts with everything
    }
}

Lock Manager Performance

Lock Lifecycle

Every lock goes through a well-defined lifecycle from creation to destruction. Understanding this lifecycle is crucial for reasoning about transaction behavior and diagnosing concurrency issues.

Converting Mermaid diagram...

Lock Lifecycle Phases

•Requested — The transaction calls lock(X). The lock manager receives the request and looks up X in the lock table.
•Waiting (optional) — If the lock conflicts with existing locks, the transaction enters a blocked state. It joins the wait queue and suspends execution.
•Granted — The lock manager grants the lock, either immediately or after waiting. The lock table is updated to reflect the new holder.
•Held — The transaction holds the lock and can safely access the data item. Other conflicting requests will be blocked.
•Released — The transaction calls unlock(X), commits, or aborts. The lock is removed from the lock table, and waiting transactions are woken up.

Duration of Lock Holding:

How long a transaction holds a lock depends on the locking protocol in use:

Short-Duration Locks: Acquired and released around individual operations. Maximizes concurrency but doesn't guarantee serializability.
Long-Duration Locks: Held for the entire transaction (until commit/abort). Used in Two-Phase Locking to guarantee serializability.
Lock-Duration Rules: Different lock types may have different duration rules. Read locks might be released early; write locks held until commit.

The choice of lock duration directly affects both correctness and performance.

Critical Rule: Never Forget to Release

Locks and Transaction Isolation

Isolation Levels and Locking Behavior
Isolation Level	Read Lock Behavior	Write Lock Behavior	Anomalies Prevented
Read Uncommitted	No read locks acquired	Write locks held to commit	None (allows dirty reads)
Read Committed	Short read locks (release after read)	Write locks held to commit	Dirty reads prevented
Repeatable Read	Long read locks (held to commit)	Write locks held to commit	Dirty reads, unrepeatable reads
Serializable	Long read locks + range locks	Write locks + range locks	All anomalies (including phantoms)

The Relationship Between Locks and ACID:

Locks primarily enforce the Isolation property of ACID:

Atomicity: Ensured by transaction logs and rollback mechanisms (not directly by locks)
Consistency: Application-level constraints + isolation working together
Isolation: Directly enforced by locking protocols
Durability: Ensured by write-ahead logging and recovery (not directly by locks)

However, locks interact with atomicity: if a transaction aborts, it must release all its locks to allow other transactions to proceed.

What Locks Guarantee

•Mutual exclusion for conflicting operations
•Prevention of lost updates
•Controlled access to shared data
•Foundation for serializability
•Predictable transaction behavior

What Locks Don't Guarantee

•Deadlock freedom (must be handled separately)
•Optimal performance (locks reduce concurrency)
•Logical correctness of transactions
•Recovery from failures
•Protection against application bugs

Locks Are Necessary But Not Sufficient

Binary Locks: The Simplest Model

The simplest form of locking is the binary lock, which has only two states: locked and unlocked. A binary lock provides mutual exclusion—only one transaction can hold the lock at any time.

binary_lock.pseudo

Pseudocode

// Binary Lock Operations
LOCK(X):
    if LOCK_STATE(X) == UNLOCKED:
        LOCK_STATE(X) = LOCKED
        HOLDER(X) = current_transaction
        return GRANTED
    else:
        // Wait until X is unlocked
        wait until LOCK_STATE(X) == UNLOCKED
        LOCK_STATE(X) = LOCKED
        HOLDER(X) = current_transaction
        return GRANTED
 
UNLOCK(X):
    if HOLDER(X) == current_transaction:
        LOCK_STATE(X) = UNLOCKED
        HOLDER(X) = null
        signal any waiting transactions
    else:
        error "Cannot unlock: not the holder"
 
// Usage Rules:
// 1. A transaction must call LOCK(X) before any READ(X) or WRITE(X)
// 2. A transaction must call UNLOCK(X) after finishing with X
// 3. A transaction cannot lock an item it already holds
// 4. A transaction cannot unlock an item it doesn't hold

Limitations of Binary Locks:

While simple, binary locks are overly restrictive. Consider two transactions that only want to read a data item:

T1: LOCK(X) → READ(X) → UNLOCK(X)
T2: LOCK(X) → READ(X) → UNLOCK(X)

With binary locks, T2 must wait for T1 to finish, even though two readers can safely access data simultaneously. This unnecessary blocking reduces concurrency and system throughput.

To address this, we introduce multiple lock modes—the subject of our next pages on Shared Locks and Exclusive Locks.

Binary Locks in Practice

Summary: The Foundation of Concurrency Control

We've established the foundational understanding of locks in database systems. Let's consolidate the key concepts:

Key Takeaways

•Locks solve concurrency conflicts — They prevent anomalies like lost updates, dirty reads, and non-repeatable reads by controlling access to shared data.
•A lock is a state variable — Associated with each data item, describing who can access it and how.
•The Lock Manager coordinates access — It maintains the lock table, processes requests, and manages waiting queues.
•Lock operations are atomic — lock(), unlock(), upgrade(), and downgrade() are indivisible operations.
•Locks have a lifecycle — From request through waiting, granting, holding, and release.
•Locks implement isolation — Different lock behaviors produce different isolation levels.
•Binary locks are simple but limiting — They don't distinguish between readers and writers.

What's Next:

Now that we understand what locks are and why they exist, we'll explore the two fundamental lock types used in all modern database systems:

Shared Locks (S): Allow multiple readers to access data concurrently
Exclusive Locks (X): Provide exclusive access for writers

These two lock modes, along with the compatibility rules between them, form the basis of practical concurrency control.

Page Complete