Concurrency Control
Concurrency Control is a mechanism in database management systems (DBMS) that ensures correct and consistent transaction execution in a multi-user environment. It prevents issues such as data inconsistencies and anomalies by managing simultaneous access to the database.
Key Concepts[편집 | 원본 편집]
- Transaction: A sequence of database operations that are executed as a single logical unit of work.
- Isolation: Ensures that each transaction is executed independently without interference.
- Consistency: Guarantees that the database remains in a consistent state after a transaction, even in the presence of concurrent transactions.
Problems Addressed by Concurrency Control[편집 | 원본 편집]
Concurrency control mechanisms resolve the following issues:
- Dirty Reads: A transaction reads uncommitted changes made by another transaction.
- Non-Repeatable Reads: A transaction reads the same data twice and gets different results due to concurrent updates.
- Phantom Reads: A transaction sees a different set of rows in repeated queries due to concurrent inserts or deletes.
- Lost Updates: Two transactions simultaneously update the same data, and one update overwrites the other.
- Write Skew: Concurrent updates create an inconsistent database state.
Techniques for Concurrency Control[편집 | 원본 편집]
The following techniques are commonly used for concurrency control:
| Technique | Description | Advantages | Limitations |
|---|---|---|---|
| Lock-Based Protocols | Transactions acquire locks on data items to control access. | Prevents conflicts, widely used. | Can lead to deadlocks, reduced concurrency. |
| Timestamp-Based Protocols | Assigns timestamps to transactions to enforce serializability. | No locks, avoids deadlocks. | Requires global timestamp management. |
| Optimistic Concurrency Control | Validates transactions at commit time to ensure no conflicts. | High performance in low-contention systems. | Rollbacks can be expensive in high-contention systems. |
| Multiversion Concurrency Control (MVCC) | Maintains multiple versions of data to provide consistent snapshots. | Supports high concurrency, avoids read-write conflicts. | Storage overhead due to multiple versions. |
Example: Lock-Based Protocol[편집 | 원본 편집]
Consider two transactions accessing the same account balance:
- Transaction A
* Reads account balance. * Deducts $100. * Updates the balance.
- Transaction B
* Reads account balance. * Adds $50. * Updates the balance.
Without locking, these transactions could overwrite each other's updates. Using locks:
- Transaction A acquires a write lock on the balance.
- Transaction B waits until Transaction A releases the lock.
- Transaction A updates the balance and releases the lock.
- Transaction B acquires the lock, reads the updated balance, and applies its changes.
Deadlock Handling[편집 | 원본 편집]
Lock-based protocols can lead to deadlocks, where two or more transactions wait indefinitely for each other to release locks. Common deadlock handling techniques include:
- Timeouts: Abort transactions that wait too long.
- Deadlock Detection: Use wait-for graphs to identify and resolve deadlocks.
- Deadlock Prevention: Ensure transactions acquire locks in a predefined order.
Applications of Concurrency Control[편집 | 원본 편집]
Concurrency control is essential in:
- Banking Systems: Preventing anomalies in financial transactions.
- E-Commerce: Ensuring consistency in inventory and orders.
- Distributed Databases: Managing consistency across multiple nodes.
- Real-Time Systems: Providing low-latency, conflict-free operations.
