<aside>
💡 Concurrency Control
the method that the DBMS uses to ensure “correct” results for concurrent operations on a shared object
- Logical Correctness → Can a thread see the data that it is supposed to see?
- Physical Correctness → Is the internal representation of the object sound?
</aside>
1. Latches Overview
<aside>
💡 Locks
- Protects the database's logical contents from other transactions.
- Held for transaction duration.
- Need to be able to rollback changes.
</aside>
<aside>
💡 Latches
- Protects the critical sections of the DBMS's internal data structure from other threads.
- Held for operation duration.
- Do not need to be able to rollback changes.
</aside>
|
Locks |
Latches |
| Separate … |
User Transaction |
Threads |
| Protect … |
Database Contents |
In-Memory Data Structures |
| During … |
Entire Txns |
Critical Sections |
| Modes … |
S, X, Update, Intention |
R, W |
| Deadlock |
Detection & Resolution |
Avoidance |
| … by … |
Waits-fir, Timeout, Aborts |
Coding Discipline |
| Kept in … |
Lock Manager |
Protected Data Structure |
1.1 Modes
1.2 Implementations
- Blocking OS Mutex
- Simple to use (System native)
- Non-scalable
- Test-and-Set Spin Latch (TAS)
- Very efficient (single instruction to latch/unlatch)
- Non-scalable, not cache-friendly, not OS-friendly
- Reader-Writer Latches
- Allows for concurrent readers
- Must manage read/write queues to avoid starvation
- Can be implemented on top of spin latches
2. Hash Table Latching
Easy to support concurrent access due to the limited ways threads access the data structure.
- All threads move in the same direction and only access a single page/slot at a time.
- Deadlocks are not possible → Everybody going in the same direction
To resize the table, take a global write latch on the entire table
Approaches:
- Page Latches → Each page has its own reader-writer latch that protects its entire contents.
- Slot Latches → Each slot has its own latch.
- Can use a single-mode latch to reduce meta-data and computational overhead.