Skip to content

Module 9 Article: Concurrency Control in Shared Databases ​

Why concurrency control exists ​

Many users may read and write the same database at the same time. Without control, updates can overwrite each other or expose incorrect intermediate results.

Locks ​

The most common mechanism is locking.

  • Shared lock: used for reading
  • Exclusive lock: used for writing

Compatibility matters. Many readers can share a lock, but a writer needs exclusive access.

Two-phase locking ​

2PL has two phases:

  1. Growing phase: acquire locks
  2. Shrinking phase: release locks

If all transactions follow 2PL, the schedule is conflict serializable.

Strict 2PL keeps exclusive locks until commit and helps with recovery too.

Deadlocks ​

Deadlock happens when two or more transactions wait for each other forever. Typical solutions include:

  • prevention
  • avoidance
  • detection and recovery

Timestamp ordering ​

Timestamp protocols order transactions using their start times. A transaction must respect that order when reading and writing data.

This avoids some lock-based waits, but it can cause restarts when operations arrive out of order.

Optimistic control ​

Optimistic methods assume conflicts are rare. Transactions proceed without locks, then validate before commit.

This works well when contention is low.

Isolation levels ​

Different isolation levels balance correctness and concurrency. Lower isolation may allow anomalies such as dirty reads or non-repeatable reads; higher isolation reduces those risks.

Exam angle ​

If asked to compare methods, mention:

  • locking is pessimistic
  • timestamp ordering avoids waiting by using time order
  • optimistic control is best when conflicts are rare

Then tie it back to deadlocks and serializability.

Built from Markdown with VitePress.