Locks in transactions; lost update

Locks in transaction processing

A lock is a variable associated with a data item that controls concurrent access. A transaction must obtain the lock before it reads or writes the item, and releases it when finished. Common modes are read (shared) lock and write (exclusive) lock; several transactions can hold read locks together, but a write lock excludes all others. In two-phase locking (2PL) a transaction has a growing phase (acquires locks) followed by a shrinking phase (releases locks, never acquires again). Strict 2PL holds all locks until commit or abort, which prevents dirty reads and cascading aborts.

Benefits

• They guarantee serial equivalence (isolation) when 2PL is used.
• Simple, well-understood and widely implemented.
• Strict locking prevents dirty reads and cascading aborts.

Drawbacks

• Deadlock can occur when transactions wait for each other in a cycle.
• Lock management has overhead (lock table, acquiring and releasing).
• Locks reduce concurrency; short transactions wait for long ones.
• Locks may be held across a network in distributed systems, and a crashed holder blocks others until timeout.
• Early release (non-strict) can cause cascading aborts.

Lost update problem

The lost update problem occurs when two transactions read the same value and both write back results based on it, so one update overwrites the other.

Example: account A has Rs 100. T reads A (100) and adds Rs 10; U reads A (100) and adds Rs 20.

T: bal = A.get()      -> 100
U: bal = A.get()      -> 100
T: A.set(bal + 10)    -> 110
U: A.set(bal + 20)    -> 120   (T's update is lost)

The correct final value is 130 in any serial order. Locking prevents this: with an exclusive lock on A, U cannot read A until T commits and releases the lock, so U sees 110 and writes 130.