30 lines
1.4 KiB
Markdown
30 lines
1.4 KiB
Markdown
# Concurrency Control
|
|
|
|
Process of managing simultaneous operations on the database without interference.
|
|
Prevents interference when >2 users access and update the db
|
|
|
|
# Lost Update Problem
|
|
|
|
A successful update is overwritten by another user - a read operation of a tuple happens at the same time as a value update of the tuple. This causes the next value update to access the incorrect value, as the read value is incorrect too.
|
|
This would be avoided if any reads are prevented until all updates are completed.
|
|
|
|
# Uncommitted Dependency Problem
|
|
|
|
A transaction reads the value of a tuple before another transaction is completed / committed. If the 2nd transaction aborts / rolls back, the value read by the 1st is inconsistent.
|
|
This would be avoided by preventing the 1st transaction from reading until the 2nd has completed ( commit or abort ).
|
|
|
|
# Inconsistent Analysis Problem
|
|
|
|
A transaction reads several values, a second transaction updates some of them during the execution of the first. This creates inconsistent values across the effected tuples.
|
|
This would be avoided by preventing reads of targeted tuples until the first transaction has committed or aborted updates.
|
|
|
|
# Conflicting Actions - General Rules
|
|
|
|
- Two transactions do not conflict if they:
|
|
- Are only reading data items
|
|
- Operate on completely different data items
|
|
- Two operations conflict if all of these are true:
|
|
- Belong to different transactions
|
|
- Access same data item
|
|
- At least on writes the item
|